- cypherpunks-legacy@lists.ogf.org

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

another remailer (again?)
by nobody＠cicada.berkeley.edu 08 Dec '92

08 Dec '92

Yes, it's the second remailer I've set up today. Gee, at this rate, I'll have the entire CPU power of the United States dedicated to remailing within four months. Just do the usual thing: mail hh(a)cicada.berkeley.edu with the header line Anon-To: or Request-Remailing-To: and the remailer does the rest. cicada and pmantis have been able to compile pgp201 and so they will soon have encrypted remailer capability. They will also soon be running pgp21 (as soon as I get a chance to compile that). They are very fast machines, so I will probably give them military grade keys. They are also very secure machines. It's too bad about not being able to use the ocf, but those machines are slow anyway and probably wouldn't be able to run pgp ever. My soda remailer should be running pgp fairly soon. And I have 1-3 remailing sites almost ready to go, probably coming on sometime next week. And hughes is working on another remailer at soda, a really fancy one. Have fun everyone! e

1 0

another remailer!
by nobody＠pmantis.berkeley.edu 08 Dec '92

08 Dec '92

I set up another remailer. All in all it took me about 30 min to compile perl and set up Hal's script. It's too easy! Just do the standard thing: mail to hh(a)pmantis.berkeley.edu with the line in the header Anon-To: or Request-Remailing-To: Have fun! e

1 0

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

08 Dec '92

We've had some discussion of anonymous addressing, which allows someone to post an address at which mail can be sent to them without people being able to find out exactly who they are. I showed how the current remailers could, somewhat clumsily, allow anonymous addresses. The problem is, with a single-remailer anonymous address that remailer sees whom each anonymous address corresponds to, so you have to trust it. Now that other encrypting remailers are up it's possible to have anonymous addresses which go through more than one remailer before going to the final destination. This, I thought, would provide a more secure address since a whole group of remailers would have to be "broken" in order for someone to find out where a given anonymous address leads. However, with the current implementation, there is a security weakness. Whomever owns the last remailer in the chain for your anonymous address can find out who you are. They do this simply by sending an anonymous message with known contents, like "test number 1598293". They then watch all messages going through their remailer, looking for one whose contents match what they sent. If they are the last remailer in the chain, when they see this message go through them, they can look at whom it is being sent to, and so they then know your true name. So, a multi-remailer anonymous address is really no more secure than a single-remailer one. Chaum, in his "mix" paper, avoided this problem by having the anonymous addresses include a random number which each remailer sees as it decrypts the incoming message. (There is always such a number, it turns out, for the RSA encryption to be secure.) He had the mix, as it passes the message through, encrypt the contents with a single-key algorithm (like DES) using this random number as the key. This way the message is transformed at each step and so if it later comes back through the same mix, it won't be recognizeable as the one it sent earlier. So the attack above fails. For this to work, the user has to save the random numbers that were used to construct his anonymous address, and decrypt the message using DES with these as keys before going on to read it or public-key decrypt it as usual. This would be quite a bit less convenient. Chaum goes on to say that these return addresses can only be used once. I was a little puzzled by the exact attack that he is trying to defend against in applying this rule. Chaum doesn't always make the attacks clear, leaving that as an exercise for the reader. I believe the problem is that, say, the last remailer in the chain could send 100 messages to a given anonymous address (all would have different contents). Then, after working its way through the remailer chain, it would see 100 messages going to the same final destination. It could guess that those 100 were the 100 it sent, especially if it repeats this test every few days with different numbers. Chaum's rule of allowing each anonymous address to be used only once makes them much less useful. These complications just go to show that real security doesn't come easy or cheap. There is still work to be done before we achieve the goal of crypto anonymity. Hal 74076.1041(a)compuserve.com

2 1

pgp2.1 released
by nobody＠alumni.cco.caltech.edu 08 Dec '92

08 Dec '92

PGP 2.1 is released. It's on soda.berkeley.edu, for your convenience, in directory pub/cypherpunks. The 2.1 release has the ability to sign a message as leave the message in plaintext. This should be used by all the pseudonyms in the group to prove continuity of authorship.

1 0

ocf remailer
by Eric Hollander 08 Dec '92

08 Dec '92

For various reasons, my remailer on the ocf is going down indefinitely. It was fun while it lasted, I laughed, I cried, but now it's over. e

1 0

Just in case you haven't heard (PGP 2.1 released)
by Derek Atkins 08 Dec '92

08 Dec '92

-----BEGIN PGP SIGNED MESSAGE----- PGP 2.1 Available - ----------------- Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. This new version of the world's most popular and politically controversial public key encryption program has numerous bug fixes over version 2.0, and several new features. For example, you can now display the MD5 hash of a public key, to facilitate verifying it over the telephone with the owner of that public key. Also, it is now possible to send via email an unencrypted signed message without putting the whole message in Radix-64 format, to make it possible to read without PGP. This is analogous to the PEM MIC-CLEAR signed message functionality. PGP 2.1 incorporates many patches from the user community to port it to more platforms. And it runs faster. Also, a lot of annoying bugs and ergonomic oversights have been fixed. PGP 2.0 fans will find many rough edges have been smoothed out. The filenames are pgp21.zip for the MSDOS executable release, and pgp21src.zip for the source code release. You must have PKUNZIP version 1.1 or later to unzip them, or they won't unzip. The primary initial FTP sites that have it are: Finland: nic.funet.fi (128.214.6.100) Directory: /pub/unix/security/crypt/ Italy: ghost.dsi.unimi.it (149.132.2.1) Directory: /pub/security/ As previously, this prohibited and politically popular program will probably propagate through the same channels as PGP 2.0. Of course, if you live in the USA, you really shouldn't be using it. If you have any questions about where else to get it, contact Hugh Miller, at hmiller(a)lucpul.it.luc.edu. Hugh can send you the latest evolving list of FTP sites, BBS phone numbers, and other sources. Philip Zimmermann Phil's Pretty Good Software -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+ ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0 JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ vs/OHzY5LiU= =nV70 -----END PGP SIGNATURE-----

1 0

No Subject
by wendtj＠jplpost.Jpl.Nasa.Gov 07 Dec '92

07 Dec '92

ruthere

1 0