December 1992 - cypherpunks-legacy

remailers, the prime user of bandwidth in the US (well, not yet)
by nobody＠soda.berkeley.edu 10 Dec '92

10 Dec '92

Could all remailer operators please mail me (hh(a)soda.berkeley.edu) the following information so that I can set up a remailer directory? There are so many remailers right now that this needs to be done: 1) address to mail to. for instance, hh(a)soda.berkeley.edu 2) how it works. what lines to put in the header, how to give it a pgp block, etc. 3) pgp key (if used) 4) how to contact the owner. this may be anonymous. you can easily set up your mail delivery file to have a Purpose: field and check it for "contact-owner" which would then forward the mail to the owner. 4) owner's name and email address (optional). I will compile all of this information and put it up for ftp on soda. e

2 1

Experiments in Digital cash
by Alan Hunter 09 Dec '92

09 Dec '92

On Wed, 9 Dec 92 02:25:49 -0800, "John Draper" <crunch(a)netcom.com> wrote: > Cm'on Alan, give us unemployed folks a break. Life's a bitch already > for us unemployed folks. To have to pay to get Cypherpunks mail > would not go very good. Just in case... I meant as an experiment in the use of digital cash and banks. I'm sure that DigiBank Inc would give us all an overdraft facility for starters. Alan

1 0

Re Anonymous address problems etc
by Alan Hunter 08 Dec '92

08 Dec '92

On Mon, 7 Dec 92 16:59:12 PST, (Hal Finney) ghsvax!hal(a)uunet.uu.net wrote: > > On the digital cash issue - I think we should get some kind of > implementation of digicash (oops, "electronic money") out for people > on the list to play with. Then, we should think of some kind of > experimental email-based game to play which would use the special > characteristics of anonymous cash. Maybe we could use the remailers, > too. Players would send cash back and forth to each other as part of > the game. Even if the tools are sort of rough at first, this could > show where the most work is needed. > > Can anyone think of a good kind of game that we could play? How about making cypherpunks a subscription mailing list, and paying contributors? Alan

1 0

PGP key generation
by ghsvax!hal＠uunet.UU.NET 08 Dec '92

08 Dec '92

Steve Witham asks about PGP's "peasant_modmult" routine, how it can subtract the modulus on each addition. It doesn't, but the code is a little misleading (taken from mpilib.c, PGP 2.1): while (bits--) { mp_shift_left(prod); msub(prod,pmodulus); /* turns mult into modmult */ if (sniff_bit(multiplier,bitmask)) { mp_add(prod,multiplicand); msub(prod,pmodulus); /* turns mult into modmult */ } bump_bitsniffer(multiplier,bitmask); } What is confusing is that "msub" looks like "mp_sub". Actually, msub is a macro defined in mpilib.h: #define msub(r,m) if (mp_compare(r,m) >= 0) mp_sub(r,m) /* Prevents r from getting bigger than modulus m */ So, msub actually only subtracts if it's necessary, as would be expected. Jim McGrath asks: > When PGP generates keys doesn't it always pick d and e to have > the same number of bits, ie 446 for the strongest type? d and e are the decryption and encryption exponents. e is chosen to be small, typically the number 17 or slightly larger. d is then about the size of n, your key modulus. p and q, the two primes which are multiplied to get n, are about the same size, usually. PGP does have some code to make sure they aren't too close to the same size (taken from rsagen.c, PGP 2.1): /* See if p and q are far enough apart. Is q-p big enough? */ mp_move(u,q); /* use u as scratchpad */ mp_sub(u,p); /* compute q-p */ if (mp_tstminus(u)) /* p is bigger */ { mp_neg(u); too_close_together = (countbits(u) < (countbits(p)-7)); } else /* q is bigger */ too_close_together = (countbits(u) < (countbits(q)-7)); /* Keep trying q's until we get one far enough from p... */ } while (too_close_together); What this does is make sure that |p-q| is > 1/128 of the larger of p or q. This is designed to make sure that p and q are both very far from the square root of n. I.e. if n were 1024 bits, p and q could both be about 512 bits, but they would be at least about 2^505 from the square root of n, foiling the square root attacks. Hal 74076.1041(a)compuserve.com

1 0

No Subject
by McGrath, James 08 Dec '92

08 Dec '92

Karl said: > Also, p and q should differ in length by a few digits otherwise > an enemy may begin to try factoring n by starting near sqrt(n). When PGP generates keys doesn't it always pick d and e to have the same number of bits, ie 446 for the strongest type? Is this the same thing? I suppose that if you are allowed leading 0s it isn't a problem at all, but if the first couple of bits were ones in each key, (a 16:1 chance) wouldn't that significantly reduce the power required to factor the PK using this approach? Just a thought, Jim

1 0

Re: PGP questions
by fnerd＠smds.com 08 Dec '92

08 Dec '92

>It's probably good to discuss how PGP works here, for educational >purposes, but I would expect people to get the source code if they >really are interested. I can give some pointers here to answers to >some of the questions people have asked. Thanks for the answers, Hal. I have been digging into the original RSA paper and the PGP 2.0 sources. By the way, sorry if my response time is long; I've been traveling for work lately. I suggested leaving the minimum set of compute-intensive routines in C and implementing the higher-level stuff in some higher-level language ("HLL"), possibly interpreted. Hal pointed out some of the crunching jobs other than modmult. Using an HLL has cons as well as pros to it. The main advantage (for my purpose here) is that C code has a lot of noise that gets in the way of understanding. This could also be improved by some coding style changes--for instance, using some object-oriented stuff (data structures that handle more of their own details) and, ahem, fewer #ifdefs... Another advantage of an HLL is ease of trying out different, er, schemes. If I used an HLL, I think it would be one that had very C-like syntax. The main drawback of an HLL is that it's another program that you have to trust. Sometimes inner parts of interpreters and compilers are hard to write so that they are correct *and seem* correct when you look at them. A couple of things they can do are automatic space allocation, garbage collection and "burning" data that's no longer in use ("garbage burning?"). -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0

peasant_multiply question
by fnerd＠smds.com 08 Dec '92

08 Dec '92

Folks-- I got out my copy of the original RSA paper, and I'm comparing it to the PGP 2.0 code. I have a question about the peasant_modmult routine (the simplest modmult in PGP). Here's pseudocode of what I think it's doing: /* Inputs: modulus, multiplier, multiplicand */ /* Output: prod */ prod = 0; set sniffer to most significant bit of multiplier; nbits = number of significant bits in multiplier; while( nbits-- ) { shift prod left 1; prod = prod - modulus; if( the bit of the multiplier being sniffed = 1 ) { prod = prod + multiplicand; prod = prod - modulus; } move the sniffer to the next bit of the multiplier; } My question is (assuming I'm understanding the code right), how can it work subtracting modulus unconditionally all the time? Won't it make prod negative sometimes, and then keep multiplying the negative number by two until it overflows? Isn't that a problem?? -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0

understandable cypher software
by fnerd＠smds.com 08 Dec '92

08 Dec '92

Folks-- A paragraph of philosophy and then some technical PGP questions. I should be able to verify with my own eyes how cypher technology works. Otherwise I'm trusting my security to somebody's black box. I should be able to write my own and test that it interacts with someone else's the way it's supposed to. I should be able to monitor the communications between my copy of a cypher product and some other, and verify that they're doing the things people say they are. Besides, I'd like to carry the crypto basics in my head "just in case." To these ends, I'd like cypher software that is as easy to read and understand and trust as possible. I'd like to start with a distilled PGP. Does this list cover the heart chambers of PGP? (Not to devalue the rest): RSA IDEA The signature algorithm (MD5?) 128 bits? Is that based on RSA? A cryptostrong pseudorandom # generator? Is this based on RSA? Something that takes keystroke delays (real, but not so good, random numbers) and makes real good random numbers? Is this based on RSA? A data compression algorithm (some variation of LZW?) A binary<-->ascii translator RSA seems to depend on doing modulo-multiply on big integers. What are the relative speeds of the different modmults in PGP (modulo processor speed)... the simplest C version the fastest C version the fastest assembler version on the processor where it matters least the fastest assembler version on the processor where it matters most? Given the time to do modmult, couldn't all the rest (including modexp) be done in an interpreter that had big ints and modmult as a primitive? What's the formula for RSA again? out = in * something ^ somethingelse mod yetanother?? I know it can't be, because the key is only one number. What is/are the basic primitive(s) for IDEA? -fnerd "Computer software must not only work, it must also appear to work." --Carl Hewitt fnerd(a)smds.com (FutureNerd Steve Witham)

3 2

Re: Anonymous address problems, etc.
by George A. Gleason 08 Dec '92

08 Dec '92

How about e-marks...? Sort of the next big thing after D-marks (Deutche Marks, you know, German currency). I don's like "crydets" because it seems like it's not straightforward pronounciation, especially when dealing with other languages; too easy to confuse with "credits," and "cry-debts" ("boo-hoo-hoo, another collection notice!")... we need a word which is less ambiguous than that. "Cryp" like "scrip" is also like "Crip," which is a very very unpleasant connotation and might leave a bad taste in the mouth of Latinos in the US. E-Marks. Clear and straightforward, easy to pronounce and not too many syllables or weird spelling tweax. -gg.

1 0

Anonymous address problems, etc.
by ghsvax!hal＠uunet.UU.NET 08 Dec '92

08 Dec '92

Chris Hibbert sent me a solution for the problem I mentioned about the last remailer in an anonymous address chain being able to discover the true name for the address. He suggested making your own remailer be the last one in the chain. If you added a little padding, so the second-to-last remailer couldn't tell (from the small size of the encrypted address) that yours was last, this sounds pretty good. And it's another reason to run a remailer, even if you had to do it manually. On the digital cash issue - I think we should get some kind of implementation of digicash (oops, "electronic money") out for people on the list to play with. Then, we should think of some kind of experimental email-based game to play which would use the special characteristics of anonymous cash. Maybe we could use the remailers, too. Players would send cash back and forth to each other as part of the game. Even if the tools are sort of rough at first, this could show where the most work is needed. Can anyone think of a good kind of game that we could play? As Eric Hughes pointed out, the cash doesn't have to be "cash", it could represent "gold" or "carrots" or any other material which exists in limited quantity. I think it was on the extropians list that Eli Brandt pointed out the need for a shorter term than "digital cash" for this cryptographic money. He suggested "cryps". I thought of "emoney" or "ecash" by analogy to "email". Here's another one: "crydets", based on "credits". Or maybe we should call them "Chaums". That way he'd be less likely to sue us for infringing on his patent. ;-) I notice he managed to cleverly name DC-nets after his initials so maybe he'd like this. Hal 74076.1041(a)compuserve.com P.S. I hear PGP 2.1 is coming out today.

2 1