December 2003 - cypherpunks-legacy

digital cash, once again
by Matt Thomlinson 17 Dec '03

17 Dec '03

What P Nave just said about beginning to give cash credit to those who receive bogus messages as a dead-letter dropoff point makes sense. If I were a subscriber to the dead-letter club, I'd receive a stipend monthly by each remailer operator for use of my account as a dead letter office. In turn, we could begin using these credits to enact some pay-per-send remailers. The remailers with dead-letter club participants would enjoy a greater amount of business (perhaps) because of their greater amount of traffic -> security through volume. Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

1 0

Info?
by Paul McKeever 17 Dec '03

17 Dec '03

Hello, Do you guys have any electronic brochures or how-to guides? Regards, Paul

1 0

Unsubscribe
by DBS5112＠ibm.MtSAC.edu 17 Dec '03

17 Dec '03

Please, UNSUBSCRIBE me...

3 2

NEEDED: Remailer list
by nobody＠eli-remailer 17 Dec '03

17 Dec '03

Does anyone keep a list of operational remailers and their PGP keys? I am new to using remailers, and I only know of a couple that I can use. I am enclosing both my PGP key and some response information that can be used to reply to this post. To make a reply to this post, you should: o Encrypt your reply with my public key o Make a text file by concatenating the response information with your encrypted reply (the response information should preceed the reply). o Mail the whole thing to the remailer at: ebrandt(a)jarthur.clarement.edu Here is my public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi1IP1QAAAEEAL0TpnNwrh/YLWxgPip1InVclRgJ9yUy6QqC4c/vaBbCEhPa x1zeupCWpHanK4c7i0JiwntS4m5a0cXQ5qoX5am5+Hw+yJVSpdbuk0PCfQmNIH4q CQs7JXELqu2YwFRBx/Qr23oKstSxQnRl9g6mJCmleEcuA0cab9twNfqELCYpAAUR tBlibGFuayA8YmxhbmtAbm93aGVyZS5jb20+ =s4dh -----END PGP PUBLIC KEY BLOCK----- And here is the response information: ---(Begin response information)--- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.3a hEwCpNUZLrF9FUsBAf9Dtq1jBDAT42Jj+XPVDwiDf88FG1hZBILWNtDQ4b13Qt7j 1Hd1FcXX8NiPFFKFgt6Y7bi+xGGg7yMowlNfMw1vpgAAAW13PygtTOl3VgX2442B hFyVNnzYpOBJ+E1z56RUsVujOIjyXIIZVWmfnrO5PaOIsSKWRSaHfWEIM9nVJaNm xgsahPw5PlJaV1+em7VEjLSeyb5NNUyOm6Rq4Fptye0o3kBVpsDRPX5LBkE4XJlU Q1fZZaGg+VLZ+e9jwiwu86j+S15imv8YHZeFxoMKD1pmfZAKqzUPdpiH4sq2UmAz OOAI4e+Vh41GmLV9qr5hdMk9A8vi6vrqOUr3ouDLdQ8+RQsvbUUHT2RtGrWyql6d mdR9QpuhgSdas3Hxre15RSVreCWozlh9Q1HGCAExu6H+DcVTLHfmNqyFZjkUmHIM /mpd1Sf331MytdIYjvIv8OaKrwiQaAKFpOyo8iigTpI1bIAUDaW+BC2JpXJv5vIq MaAPV8zsqNywNtexLGvg32v2JELGoHNegycUwDYnKCwmWEtr9acEJ3HOQ4OWnb2W dUr/Dd5akY6L+07AWFKa6w== =Geng -----END PGP MESSAGE----- ---(End response information)---

1 0

REMAIL: Cover traffic
by Hal 17 Dec '03

17 Dec '03

Several people have suggested that cover traffic is more valuable than I had suggested in helping prevent tracing of messages through remailers. I drew up some diagrams to show what I mean. Suppose we have remailers R1 through R6 exchanging dummy messages all the time that are introduced into the remailer network by cover traffic sources C1 through C3: C1 C2 C3 | | | | | | | | | | | | V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 Now user U1 sends to user U2 through some remailers in this network: C1 C2 C3 U1 | | | | | | | | | | | | | | | | V V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | V U2 As you can see, it doesn't exactly take Sherlock Holmes to figure out who is talking to whom. If the "true" traffic through the network is light and latencies low, someone monitoring the whole network can track messages in this way. Now, suppose we also had U3 send to U4. Then there is some benefit: C1 C2 C3 U1 U3 | | | | | | | | | | | | | | | | | | | | V V V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | | | | | V V U2 U4 An observer may be able to deduce that U1 and U3 are sending to U2 and U4, but they can't tell which is sending to which. So the cover traffic had some effect. But consider: you can get the same result from a SINGLE batching remailer: U1 U3 \ / \ / \ / R1 / \ / \ / \ U2 U4 Here we also have U1 and U3 sending to U2 and U4, without being able to tell which is which. It has also been suggested that "bit-bucket" addresses, people who would receive messages from the network and discard them, would help. Here is how cover traffic might look with bit-bucket addresses B1 through B3: C1 C2 C3 | | | | | | | | | | | | V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | | | | | | | | | V V V B1 B2 B3 Here again, though, if true message traffic is light, and U1 sends to U2, we will have: C1 C2 C3 U1 | | | | | | | | | | | | | | | | V V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | | | | | | | | | | | | | V V V V B1 B2 U2 B3 Again, the changes in the background pattern of communication reveal the true messages. The only way this cover traffic will work is if there are a very large number of traffic generators, (C's) and a large number of bit-bucket addresses (B's). Even then it will mostly serve to cover messages which are from C's to B's. And you still have the problem that the B addresses may become well known (people have to find out about them somehow), making this analysis easier. It has also been suggested that in pointing out these difficulties I am overlooking the fact that at least the cover traffic makes the eavesdropper's task more difficult, as he now must monitor the whole network. But I think he has to monitor the whole network anyway. If I send a chain-encrypted remailed message through half a dozen remailers (even without cover traffic), the observer must watch that message going into and out of each of those remailers in order to see where it finally goes. Looking at only one remailer will not help. So, since the eavesdropper must monitor the whole network in order to follow messages even without cover traffic, I think it is fair to point out that adding cover traffic doesn't help much against an eavesdropper who can monitor the whole network. The real solution, as suggested by the diagrams, is to have a large volume of true remailed messages in the network - messages which go to a wide variety of people. Individual users can protect themselves to some extent by serving as cover-traffic generators and bit-bucket receivers; but this does not protect other users who are not able to perform these functions. Hal

1 0

Remailers needed NOW. Help.
by an48138＠anon.penet.fi 17 Dec '03

17 Dec '03

------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Remailing TO anon.penet.fi?!
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

Can I remail using say the hh(a)soda.berkeley remailer TO an anonymous address of anon.penet.fi? Say an1234(a)anon.penet.fi. Normally you CAN send mail to such an address, but if you set up an X-Anon-Password then you must use it. So if someone sent mail to password(a)anon.penet.fi via one of your remailers, then no one else could mail to anon penet fi via that remailer! Is the solution to use na1234(a)anon.penet.fi instead of an1234(a)anon.penet.fi? Might you instead work out a deal with Julf to do this switch for your remailers? Or build it into your remailers yourselves. This way someone could send mail to an1234(a)anon.penet.fi, and your remailer would swap it with na1234(a)anon.penet.fi. Am I missing something? -Bozo

1 0

Article: Common Randomness in Info Theory.....
by baum＠newton.apple.com 17 Dec '03

17 Dec '03

I thought this might be of interest to cypherpunkers. The full title is: Common Randomness in Information Theory and Cryptography - Pt. I: Secret Sharing by Rupolph Ahlswede and Imre Csiszar in IEEE Transactions on Information Theory V39 #4 It talks about generating a common random key at two terminals without letting an eavesdropper obtain info about the key. ************************************************** * Allen J. Baum tel. (408)974-3385 * * Apple Computer, 20525 Mariani Ave, MS 305-3B * * Cupertino, CA 95014 baum(a)apple.com * **************************************************

1 0

Remailers needed NOW. Help.
by an48138＠anon.penet.fi 17 Dec '03

17 Dec '03

Dear Cypherpunk-remailer operators: I need an immediate answer, so I thank you now. I am sending the PGP FAQ by Gary Edstrom and my "Here's How to MacPGP Guide!" to anyone who sends me mail with subject "Bomb me!". It is very easy for me to do this, one keystroke in fact. I am averaging 6-12 requests a day, and expect this to top 40-50 if I start advertising in other Usenet groups. As each piece in the 5-part package is about 20-45K, it turns out that I am pushing 1-2MB of mail through anon.penet.fi a day. Guess what? Julf sent me a e-letter today asking what's up. My return letter and offer of support of his remailer may appease him, or it may not (if his remailer just can't take it). I am currently being forwarded the messages from the Cypherpunks mailing list and I have noticed that YOUR remailers need more volume! I offer to switch from anon.penet.fi, and divide my five-part package (20-45K per part) among five or less of your remailers. This will amount to 250-500K per remailer a day, and may reach twice that if I advertise the service better. They will arrive about 5 seconds apart, in volumes of 3-6 per session, perhaps 2-3 times a day. I need to know RIGHT NOW, which remailers can handle this, and will remain STABLE. I worry that if one fails, I will not receive notice of this like anon.penet.fi gives, or the situation will become a nightmare for whatever reason. I am not using encryption, an CANNOT do so since it would require me to re-encrypt it for EACH new address. I am NOT willing to do this. I will receive your answer faster if posted to the list, and I think the answer will be of interest to many (which remailers can handle volume and are the most stable...). I would like to use the normal header and I need to know EXACTLY how to format this (one space, "::", "Request-Remailing-To: address", one space, and message?). I also need an idea of the time-lag involved in each remailer. Anon.penet.fi adds from 1 hour to 2 days lag time, but is very reliable. I do not wish to chain my remailing, but I COULD do this in a fixed way if you wanted me to. I have a SIMPLE file containing five single- line Unix commands which contain ONE csh environment variable which I assign to the person's e-mail address. I am executing this remotely using rsh. I don't know Unix well enough to do much more than this! Thank-you. Looks like I'm interested in your remailers after all :-). -Xenon ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Remailers needed. My survey.
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

I have now picked five of your remailers for distribution of the PGP FAQ in four parts and my "Here's How to MacPGP!" guide. The top five in this list are the ones that worked out. 1: Remailer accepts only plain text headers. 2: Remailer accepts both plain text and encrypted headers. 1 hh(a)pmantis.berkeley.edu <-[Very fast.] 1 hh(a)cicada.berkeley.edu <-[Very fast.] 1 hh(a)soda.berkeley.edu <-[Very fast.] 2 elee7h5(a)rosebud.ee.uh.edu <-[Very fast.] 2 hfinney(a)shell.portal.com <-[Fast. Ugly header.] 1 00x(a)uclink.berkeley.edu [Fwd: hh(a)soda.berkeley.edu] <-[Very fast.] 2 hal(a)alumni.caltech.edu [Fwd: hfinney(a)shell.portal.com] <-[Fast.] 1 nowhere(a)bsu-cs.bsu.edu <-[Way too slow.] 1 remail(a)tamsun.tamu.edu <-[Way too slow.] 2 ebrandt(a)jarthur.claremont.edu <-[Way too slow.] What does the "Fwd:" mean (from the PGP FAQ)? Now, would someone send me a script that I can run that will assign csh environmental variables (I use setenv) B1 through B10 with a random combination of those five remailer addresses? I will then hop each message off two remailers. Do you have any objections to this? Suggestions? I pissed Julf off without realizing the "size" of the problem beforehand. Are there any remailers I've neglected, which are FAST? If this works out, I may inadvertantly become your best "customer" ;-). -Xenon P.S. I sent about 8 rapid-fire (3-5 seconds delay) packages JUST through hh(a)soda.berkeley.edu and they came through without a glitch. This was about a full meg of traffic. Can these remailers take this? Anon.penet.fi limits messages to 48K. Do these remailers have practical limits? What about the normal size restriction on e-mail; what is this understood to be, if I need to mail to most anyone including AOL, Compuserve, BBSs and overseas? P.S.S. That's "N A THIRTY-EIGHT ONE-THIRTY-EIGHT" with Subject "Bomb me!". Do NOT tell people "an", or just hit the 'r' key. Then I'll HAVE to route the guides through anon.penet.fi since I wont know your real address. A bit of this is OK, but not a lot.

2 1