September 1993 - cypherpunks-legacy

anonymous routing
by bill＠twwells.com 05 Sep '93

05 Sep '93

I've been thinking about the problem of sending anonymous e-mail without using explicit routing. Here's one solution. Each message is comprised of two parts, an encrypted address and the data to be transmitted. The encrypted address has N parts, each encrypted so that it can be decrypted by one remailer. These N parts each contain information such that M of them can be used to reconstitute the destination address. Note that no indication is given of which remailer decrypts which; a remailer is expected to attempt decryption of all of them and to check for success. When a remailer is able to decrypt a piece, it replaces it with its decrypted value. It then remails the results, either to a randomly chosen remailer or to the destination, if it has the M parts. Sounds like the mail will never get delivered? Possibly. N pieces in the message M pieces needed to recover the addresses R remailers If I haven't screwed the math, H = R * (1/N + 1/(N-1) + 1/(N-2)....1/(N-M+1)) That is, the average number of hops to deliver a message will be the product of the size of the remailer pool and a factor that is purely a function of the address information. This number amounts to an appreciable fraction of the remailer pool unless the number of pieces is very large. For example, with just two pieces needed and 20 pieces provided, you'll hit about 10% of the remailers. Combine this with two things: make all messages the same size and create a "background" set of noise messages and I think that just about covers connecting sender to receiver. The only exception I can think of is that, since a message going into the system has the same data going out, if the bad guys see it in both places you're screwed. There's an obvious solution to that that I've overlooked, right?

1 0

REMAIL: 9/6/93
by Karl Lui Barrus 05 Sep '93

05 Sep '93

With all the new remailers, and more to come soon, I thought I'd post an updated list. Updated public keys and unix scripts should be available soon; hopefully I'll update the dos batch files this weekend as well. NOTE: my new remailer (elee9sf(a)menudo.uh.edu) is not on this list, partly because I don't expect it to run for any great length of time. It is more of an experiment to support PGP and RIPEM at the same remailer. If you missed the public keys, mail to me and I'll send them. -----BEGIN PGP SIGNED MESSAGE----- Cypherpunk anonymous remailers, 9/6/93 Q1: What are the anonymous remailers? A1: 1: nowhere(a)bsu-cs.bsu.edu 2: hh(a)cicada.berkeley.edu 3: hh(a)pmantis.berkeley.edu 4: hh(a)soda.berkeley.edu 5: 00x(a)uclink.berkeley.edu 6: cdodhner(a)indirect.com 7: hal(a)alumni.caltech.edu 8: cs60a-qu(a)cory.eecs.berkeley.edu 9: ebrandt(a)jarthur.claremont.edu 10: catalyst(a)netcom.com 11: sameer(a)netcom.com 12: remailer(a)rebma.mn.org 13: elee7h5(a)rosebud.ee.uh.edu 14: hfinney(a)shell.portal.com 15: remail(a)tamsun.tamu.edu 16: remail(a)tamaix.tamu.edu 17: remailer(a)utter.dis.org 18: remailer(a)entropy.linet.org 19: remail(a)extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-19 support encrypted remailing requests 19 special - header and message must be encrypted together 12,17,18,19 introduce larger than average delay (not direct connect) 12,17,19 running on privately owned machines ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Mail to me (klbarrus(a)owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name(a)cs.utexas.edu 2: group.name.usenet(a)decwrl.dec.com 3: group.name(a)news.demon.co.uk 4: group.name(a)news.cs.indiana.edu 5: group-name(a)pws.bull.com 6: group-name(a)ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIoT9IOA7OpLWtYzAQEyNQP/YeinL8uNCiOLDLVr0U+keX2LOkdyftHb FYOc56yGa+GcvqZ0KwqQk3cIAhZjdpNoRv6HcFHUcbD25lh77vyP/F/8OCXtRrG1 6708o0gGPcj2CSuzYygSFlfey4bv9FAsIgwe71oHpe5W0u/XxHUlaBFebi+u0310 lRTAiuBNRhI= =CcA+ -----END PGP SIGNATURE-----

1 0

Remailer Reliability
by norm＠netcom.com 05 Sep '93

05 Sep '93

sameer(a)netcom.com (Sameer Parekh) says: > Didn't someone mention a while back a scheme by which a > message can be split up into a bunch of parts and only requires about > 50% of them or so to be completely rebuilt? Something like that would > be very useful I think to deal with remailer reliability problems. > That would require a good deal more user work though. There was a paper sometime back (10 years I would guess) called "Sharing Secrets". For any j and k such that 0<j<k you could arrange that the secret was divided into k parts, any j of which sufficed to reconstruct the secret. Each part was the size of the secret. Any collection of less than k parts yielded absolutly no information even with exhaustive search. If I have a third degree real polynomial y=f(x) and have computed y for six different values of x then the polynomial can be resonstituted from knowing any four of those <x, y> pairs. The secret was the value of f(x) for yet another public value of x. The paper described how to do this in finite fields.

1 0

Two digital cash technical papers
by nobody＠shell.portal.com 05 Sep '93

05 Sep '93

There are two papers at ftp.cwi.nl descibing some of the mathemathics, /pub/CWIreports/CS/CS-R9318.ps.Z and /pub/CWIreports/CS/CS-R9323.ps.Z CS-R9318 N. Ferguson "Single Term Off-Line Coins" CS-R9323 Stefan Brands "An Efficient Off-line Electronic Cash System Based On The Representation Problem"

1 0

Re: Gubment Bombmaker's Cookbook
by George A. Gleason 05 Sep '93

05 Sep '93

This case brings up the same larger issue as does privacy in all its forms: the question of whether and to what degree the protection of the Bill of Rights extends into the realm of electronic media. I strongly suggest it's time to start a grassroots campaign for a new constitutional amendment which extends all constitutional protections to include and encompass "any electronic or optical or other means of information storage, processing, and communication." With a relatively liberal, pro-technology administration in the White House, this stands a better chance of passing now than it did a few years ago. A constitutional amendment would put BBSs etc. on the same footing as the spoken word and the printed page. Without this, we're doomed to a future of petty tyrrany and censorship. -gg

1 0

A question about pasting
by nobody＠eli-remailer 05 Sep '93

05 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- This probably a naive question, but: Is there any way, using a remailer, to paste something into the header that will provide a return address (different from the reamiler's) that can be recognized by a garden variety unix mail program? Because it seems to me that if it is, then it would be possible to set up a mail forwarding site that would work in the following way: 1. A user would send in and register, possibly (preferably) via a remailer chain, a public-key and a remailer return address. A remailer return address would be a PGP encrypted command bundled with a remailer address; the PGP command would cause the remailer to forward the mail to the user through a chain of remailers. 2. These would be stored under an alias, either user-defined or automatically allocated (like anon.penet.fi). 3. Once registered, the server would send encrypted mail back to the user via the chain, and request that the user take some specific action (ie., send mail with the a random ten character string in the subject line, or whatever) to verify the address. This would prevent people from creating anonymous identities that forwarded mail to someone else. 4. Once the identity was registered and confirmed, then whenever mail is sent to that address, the forwarder will encrypt it with the public key and use the remailer chain to forward the mail. The identity of the person sending mail to the alias and the subject line would be buried in the cyhpertext. 5. The server will also make the public key of all identities available via a mail request, so that signatures can be verified by people who want to do that. The whole point of this is that it would then be possible to have mail that's very secure (except for traffic analysis). You could use PGP encrypted outgoing mail to everyone, even people who don't know or care about remailers. Your sysadmin wouldn't know what your outgoing mail contained or who it was to. None of the people operating remailers would know that either, because you're using a chain. If you could paste a line into a header that would allow others to mail to your alias by just pressing 'r' on their mailer, then you wouldn't be asking your correspondents to sacrifice any convenience on their end. The people running the alias server wouldn't know who you really were, and niether would any of the people running the remailers on on the encrypted return chain. The result of all this would be that all of your incoming and outgoing mail would be encrypted, and the identities of your correspondents would be hidden, as would the contents of your letters; and you wouldn't be depending upon any single person to hold your secrets for you, because none of the individual remailers would be able to piece anything together, and the alias server wouldn't know anything about you at all. And all of this would be 100% compatible with the existing email system (you could communicate with non-participants). It's almost an axiom that any simple idea like this can't work, or else it would already be implemented. That suggests to me that you *can't* paste something in the header that will automatically route replies to an alias rather than back to where the letter came from. Is that the case? Alex astrashe(a)nyx.cs.du.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLImSLbGKvmrRrQghAQGs8QQAsVR4TKqKEda04dYarEuwWgwN5eejQbKP SCdRwEYhl7UhzcVuTCoRezHeqLYWa56a00hBu3qGY+HE/0VPWns7bmNodt4Ykdxl sbpPfwTwS+dPDrQBUAIhYSxT1A1dxhjkI5uKK7zj4PqbUjcp0e9BBuiClQk6Yz3K WXmsJ3byvEw= =xMN5 -----END PGP SIGNATURE-----

1 0

REMAIL: sendmail invocation
by Karl Barrus 05 Sep '93

05 Sep '93

I just adjusted the sendmail invocation in the remailer scripts on menudo to include the -oi option ("/usr/lib/sendmail -oi "). This option tells sendmail to not treat a period on a line by itself as the end of input. (I remember having fun posting a message where I showed forging a usenet post - my post had such a line, and the rest of the message kept on getting truncated. Miron brought the -oi option to our attention!) However, it just occured to me that this is a simple, if unplanned, way for people who have signatures automatically appended to messages to use a remailer and have trailing lines cut! No fancy "cut here" marks for the scripts to recognize, let sendmail do the work! On the other hand, I plan to not use sendmail in the long run. I plan to upgrade to an smtp package (hopefully to avoid logging like syslog) sent to me by Peter Honeyman, so I'm going to leave the sendmail invocation with -oi. -- Karl L. Barrus - klbarrus(a)owlnet.rice.edu

1 0

REMAIL: RIPEM and PGP remailer
by Karl Lui Barrus 05 Sep '93

05 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, I have turned my old account (elee9sf(a)menudo.uh.edu) into a cypherpunks remailer that supports BOTH pgp and ripem. In addition to the pgp pasting token :: Encrypted: PGP there is also a ripem pasting token :: Encrypted: RIPEM I've just tested the remailer with pgp, ripem, pgp nested inside ripem, and ripem nested inside pgp, and all the messages have come back successfully. The installation went fairly quickly with Sameer's scripts; I essentially added the necessary lines to the maildelivery file, copied the pgpmail.pl file to ripemmail.pl (that's what I indicated in the maildelivery file), altered ripemmail.pl to recognize RIPEM message delimiters, and changed around the string that is built with the $system call. I apologize to those who have asked for a RIPEM remailer for taking so long; I was bogged down trying to get RIPEM compiled on rosebud, an HP/UX (cc, c89, -Aa flags: nothing worked; no gcc or disk space to install gcc, unproto didn't help - I now think the compiler is way broken). The only drawback is that account is due to expire sometime. Plus, if many people decide to support ripem in addition to pgp the scripts are going to need some reworking :-) In order to update the dos batch files I'll need an MSDOS ripem executable - has anyone seen any? (Apparently I don't have a command line compiler to build it myself; I have Turbo C++ for Windows) Here are the public keys: For the pgp half - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyIBzwAAAEEALgRUlovklKVnasbE6qyNB82RL8emHh6+BwRwt49Yqt/YJaP Yl7V6k83/pnTE4w73S6rcWBo9jrSH1u1/Fcz7uUbRmGhteuMBEnB64wPqbxKEIrt vKJAx4xuNkTPGeNBCGOq5RtiEHbEt99hKF2H6lk9iLb8UwQCnV45xNlD3J7pAAUT tCByZW1haWxlciA8ZWxlZTlzZkBtZW51ZG8udWguZWR1PokAlQIFECyICuyDgOzq S1rWMwEBE44D/3Wwl0SLFvcN6BHe3BJhh6m1KBs3pRXsy2SBGN/y3+/NVRHbYhgy Q0MLEAPJ0PZnsJjH1pIyEDnoybcIvFyd5B3e9txawQJvaq238dyuzj5nzaTxe43H KUlh52fJzLCvXNa035p5ApvkaD1PpdAo6Vk3BGuYGOtEtGQLzLFntaqv =kIeo - -----END PGP PUBLIC KEY BLOCK----- and for the ripem half - -----BEGIN PUBLIC KEY----- User: elee9sf(a)menudo.uh.edu PublicKeyInfo: MFowCgYEVQgBAQICAgkDTAAwSQJCAXLNDW+7UU+XsgEfhDVdhgH0gq68Ss056URr 3VDg7lSUu61anW2wABEeVEzCgQwYR4/hYdV3rojbADx9UOAp+cOzAgMBAAE= MD5OfPublicKey: B6DB0C696304C9092F8A4493326461D3 - -----END PUBLIC KEY----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIlj+YOA7OpLWtYzAQEx8gP/YejO5r9+dCAQa2jdypuQTQmZOeLvXZLu UKK9sfn6Q2HJu0cp+ll0JVKh4qujLCmCFgFAeXwMbdBibJLByIowKzul6W0dNUEq haLRnhrI/iGiDO9VgD8463TpA7BHxM13t7iJp5TaaYI3KfwIxj7J6H43bjr9Ea6u aniKxu5WrDI= =imPY -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

Denning in Govt Comp News
by L. Detweiler 05 Sep '93

05 Sep '93

FYI, on sci.crypt W.H. Murray passes along quotes of D. Denning in an article in Government Computer News, p14, Aug. 30, 1993 by Kevin Power. If anyone could scan this for the cypherpunk collection it would be appreciated. ===cut=here=== From: WHMurray(a)DOCKMASTER.NCSC.MIL Subject: Denning on Skipjack Date: Fri, 3 Sep 1993 00:25:00 GMT In Government Computer News, p14, August 30, 1993, Kevin Power quotes Dorothy Denning as saying "I am 100 percent certain that there are no weak keys." William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From: WHMurray(a)DOCKMASTER.NCSC.MIL Subject: And again, Denning on SKIPJACK Date: Fri, 3 Sep 1993 02:30:00 GMT In the same article kevin Power quotes Denning as having said "The people at NSA have done more to evaluate than the public algorithm in DES. They're way ahead of the game." I hope Dr. Denning never said anything like that for the record. Even if it were true, it would not be knowable. It would be unprofessional to make such an unscientific assertion. William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From: WHMurray(a)DOCKMASTER.NCSC.MIL Subject: Denning and the cost of attack against SKIPJACK Date: Fri, 3 Sep 1993 02:20:00 GMT On page 14 of the August 30, 1993 issue of Government Computer News Kevin Power reports that Dorothy Denning told the Computer System Security and Privacy Advisory Board that SKIPJACK would not be compromised by exhaustive attack methods in the next 30 to 40 years. [...]

1 0

Phil Z Comments on ViaCrypt
by edgar＠spectrx.Saigon.COM 05 Sep '93

05 Sep '93

I received the following comments on ViaCrypt from Phil Z. Reposting here with permission. I'll try to forward a summary of your comments. ==================================================================== Subject: Re: Your visit To: spectrx!edgar (Edgar W. Swank) *Edgar* Date: Wed, 1 Sep 93 20:40:08 MDT From: Philip Zimmermann <szebra!columbine.cgd.ucar.EDU!prz> Hello Edgar. Thanks for your hospitality. I enjoyed our conversations during my visit. The PKP/Viacrypt contract requires that ViaCrypt use THEIR OWN RSA cryptographic engine, not PKP's or RSADSI's. I will be working closely with them to ensure that they do a good job on that. Actually, RSA calculations are fairly straightforward, and it's hard to screw them up. I will probably try to get them to stick with my own keygen routines, if they are allowed to use them in the PKP contract. The keygen stuff would be the most important place to look for any security holes. My discussions with ViaCrypt's president, Lenny Mikus, and his programming staff, suggest to me that they are genuinely interested in making a very secure product. It's possible, I suppose, that maybe I could talk to ViaCrypt about maybe publishing the source code for the rest of ViaCrypt PGP, minus the RSA engines that the PKP contract won't let them publish. We'll see. The current plans are for them to use the straight PGP source code with no changes except for using their own RSA engines. So publishing the source code would not yield many new insights anyway, since it's the same. Other than as a confidence builder, which is nice to have. You may repost this to cypherpunks if you wish. Phil -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0