December 2003 - cypherpunks-legacy

Re: Government-Controlled Trust Hierarchies
by frissell＠panix.com 17 Dec '03

17 Dec '03

At 11:44 AM 7/27/94 -0700, Timothy C. May wrote: >I suggest we look very closely for connections between TIS and >Microsoft, Apple, Novell, Sun, and any other major OS providers. I >believe TIS is preparing an SKE system that involves the "proof of >identity" notary system Apple and RSADSI are now using, that involves >mandatory selection of escrow agents (*), and that will be widely >deployed in upcoming future operating systems, probably in Chicago in >1995 and maybe in Apple's System 7.5 in '95 as well. > I've often wondered how "proof of identity" systems cope with the multiplication of entities problem. Who exactly *is* XYZ Corp, Trust, Estate, Partnership, Company, etc? DCF "Justice Department lawyer admits in open court that we are ruled by an 'anonymous horde, a leviathan' -- in litigation over the design of the Health Security Act."

1 0

Re: LITTLE BROTHER INSIDE
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

yusuf921(a)raven.csrv.uidaho.edu said: >the best defense is to say you forgot it, it was some program you didn't >want your children editing at the time, > >then again whats a year in jail for contempt of court compared to >20-30 (or whatever) years for child pornography > So, does anyone know what the record stay on comtempt charges is? -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

3 2

RE: New Threat on the Horizon: Software Key Escrow
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> From: Timothy C. May > Putting Microsoft's feet to the fire, getting them to commit to *not* > including any form of software-based key escrow in any future releases > of Windows (Chicago or Daytona) could be a concrete step in the right > direction. Ditto for Apple. > ................................................ Does anybody have any experience doing stockholder resolutions? Even though they seldom pass, they are one way of pressuring a company to do things, and if well written can have a big impact (e.g. a resolution that Microsoft/AT&T/Apple/Network23 "never compromise the privacy of their customers data by using key escrow" puts management in a position of either supporting the resolution (yay!) or saying "no, sometimes we're willing to compromise our customer's privacy", followed by weasel words about how it's Good For America and therefore Good For General Motors or whatever. Thanks; Bill

1 0

Re: New Threat on the Horizon: Software Key Escrow
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> On Tue, 26 Jul 1994, Jef Poskanzer wrote: > > . . . [description of key escrow scheme] > > I don't see any defense in this description against using someone > > else's public key. The feds could still decrypt such messages, > > but wouldn't know who was talking. At least not from the envelope. That was one of the main objections pointed out by the folks at the Karlsruhe workshop. The solution is to have some component, I forget which but probably the session key, public-key signed with the sender's private key, and have that key include a key certificate signed by the Authorities. Did cause some minor embarassment for the statists, who hadn't apparently noticed it, but works fine. On the other hand, if you lose your wallet and your National ID SmartCard II, which has your signed IsNotACrook Citizen Credentials on it, and your card PIN is still set to 1200 like your VCR, and somebody guesses it, well it's a real shame that you have to get it replaced and change your Security Number. Bill

1 0

Re: Encryption Algorithm for Pagers
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> From: jgrasty(a)pts.mot.com (Joey Grasty X3697 P6611) > I am looking for a simple encryption algorithm suitable for use in pagers. [small, fast, low CPU needs, small keys] > 5. EXPORTABLE <-- yeah, I know Exportable is easy - you just need to get a *license*. Since you're at Motorola, you're a big enough company to talk to NSA and have some clue of having them approve it, as long as you give them an algorithm simple enough for them to crack, or dependent on a key you give them, or whatever. An alternative is to develop the code overseas and import it; I don't know where you're doing your pager hardware, but this does mean installing firmware overseas (not a major problem if you use flash eproms, though still annoying.) But you can use any algorithm you want, and get to complain to the COmmerce Department about how your US firm had to use overseas labor because of hostile export laws. Also, exportable doesn't mean you import it to the country you want to sell it in; Singapore may not be willing to let you import there something that the NSA let you export from here, and China may not either. As far as protocols go, you need to look at your threat model - are you worried only about random eavesdropping, or do you want something secure enough the NSA can't crack? Ron Rivests's RC2/RC4 protocols are export-licenseable, as long as you limit them to 40-bit keys, and are willing to license the code from RSADSI. It has the advantage that your data will probably be only readable by professionals for the next few years, though I don't know if it's small enough for your application; speed should be fine. On the other hand, the basic wimpy Linear Feedback Shift Register random number stuff, while not highly secure, may be adequate for your needs; use a mode like 32-bit randoms of which you use the bottom 8 bits to XOR with your data, and start it with an initialization vector you send with the message so the address message isn't always constant for a given user. I guess I really hate to suggest putting wimpy encryption in an important global system like a pager net, though it's better than the current totally non-private version. The big advantage you have for current pager applications is that most messages are short, max 80 or 256 characters with averages probably 20 characters, so there's not much known plaintext (assuming you do the important step of using a 1-character abbreviation for the pager system's own phone number, which is otherwise transmitted on a large percentage of pages...) On the other hand, you *do* have the known plaintext of the pager address in each message, which is serious risk. Actually, Blum-Blum-Shub looks like it should be a fairly small program, but I don't know how long a number you need to use to make it reasonably secure - if it's in the 128-bit range you're fine. (it's probably less likely to be exportable than DES, I suppose :-). It's slow, but you may be able to pre-compute. Also, you can gain some efficiency by splitting up the pagers into 128/256 groups, send an unencrypted group-id as the first byte, and only decode if that matches. That means you don't need to watch most of the messages that go by, and have extra slack time to decode the messages in your buffer that may be meant for you while ignoring the rest; this does imply that the transmitter would queue up messages so that messages from the same group don't go out within N messages of each other. Bill

1 0

Cryptosplit note
by rjc＠powermail.com 17 Dec '03

17 Dec '03

It uses rand() when it needs random numbers for the coefficients of the polynomial. I don't know what kind of security risk that poses, but it really should be using something better. Where can I get Blum-Blum-Shub source or documentation on the algorithm? -Ray

2 1

Re: XSPLIT now own ftp.wimsey.bc.ca
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: XSPLIT takes a file, generates n-1 random numbers, writes those random numbers : out to each of the n-1 files, and for the nth file it takes the XOR of all N : random numbers, and XORs it with the plaintext. This way, you get to split : your file in such a way as to require all pieces of it in order to rebuild it. Where do you get your random numbers? (This could be susceptible to the usual PRNG reverse-engineering techniques...) G PS I know I should fetch it and look for myself, but I'm fighting alligators here again.

2 1

us.* heiarchy--scary
by nzook＠math.utexas.edu 17 Dec '03

17 Dec '03

The following is only tangentally c-punk. It is also long. Ctrl-C now if that is your only concern.

2 1

Proposed us.* heirarchy
by nzook＠math.utexas.edu 17 Dec '03

17 Dec '03

The following is only tangentially c-punk, and long. If, based on that, you don't want to read it, please hit ctrl-C now. Nathan

1 0

I will Kill SKE for You
by frissell＠panix.com 17 Dec '03

17 Dec '03

How to kill SKE? Open offer. For $100 I will apply for an escrowed key and get it delivered to you (without actually posessing the key material). I will also apply for a key as the representative of your corp, trust, partnership, etc. For an additional fee I will legally change my name to yours, get a key in that name and then change my name back. All transactions can be completed in cash. DCF "No racist - I support the permanent elimination of federal income taxation for African Americans to compensate them for the suffering of slavery."

1 0