December 2003 - cypherpunks-legacy

re: The Packwood Memorial Diary Server
by dave_taffs＠rainbow.mentorg.com 17 Dec '03

17 Dec '03

Jim Miller writes: >If true, I guess the next question becomes: How can you offer a service >to the Internet, but make it impossible for a Bad Guy to physically locate >you? >Perhaps the server shouldn't stay in any one location for very long. >Bring it up and post an Internet address. Operate for a few days, then >shut it down and move to some new location, with a new Internet address. You can use the Internet itself as a storage device. I've seen articles about how you can use the ether between here and the moon as a storage device, sending (e.g. optical or radio) information up to the moon, bouncing it off, receiving the echo, and then resending it. It takes a few seconds I think, which allows a fair amount of storage, depending on the bandwidth. So, for example, you have a bunch of net.sites that receive stuff and send it back. Of course, you have to wait for it to come around again to your neck of the Net-u-verse to read it again, but then you don't have to pay for as much disk storage, as all your friends on the 'net will let you use what they have in their store-and-forward mechanisms. The disadvantage is that it relies on a form of security by obscurity; once people figger out what you are doing, they may get pissed off. If you use it wisely however, and just gradually increase the bandwidth over time, eventually you may be able to get everybody else to pay for the disk space to keep _your_ data, without anybody being the wiser. The Internet as a (w)hole must have enormous capacity at this very minute. -- O_O 01234567 dave_taffs(a)mentorg.com | . . ^ "Kolmogorov-Chaitin measures of complexity are | (_:_) MGC != me very exciting." -- Tim May on 12/02/93 |

1 0

Re: clipper pin-compat - Not really
by freeman＠MasPar.COM 17 Dec '03

17 Dec '03

Also useful would be a Clipper in-circuit emulator -- a pin-compatible head connected by cable to the computer of your choice, where you could do whatever you wanted to the data, in software of your choice. I suspect that such a device is relatively easy to construct. It could even have a real Clipper inside it (possibly the one you took out of your 'phone), for use when you wanted to pretend to be doing what the powers that be wanted you to do. -- Jay Freeman

1 0

Re: Anonymous Anonymous ftp
by loki＠nately.UCSD.EDU 17 Dec '03

17 Dec '03

:Jim Miller asks for an example: : : :> > - prepaid mailers, good for sending a packet to a :> > destination. With the final address nested insided a :> > series of encrypted packets, no mix along the way can :> > identify Bob without extensive collusion with other :> > mixes. :... :> I understand how you can do 2-way anonymous communication via message :> pools and Penet-style systems, but I don't "get" prepaid mailers. Could :> you post an example showing how two people can converse anonymously via :> prepaid mailers. : :I'll use Lisp-like notation to encapsulate the sending of a packet to :a remailer "Bob." If Alice wishes to send a packet to Bob, she creates :this packet: : :(Bob (more stuff)) : :I'm assuming encryption, which several remailers support and which all :users and all remailers should be using. : :Bob gets this packet, decrypts with his private key and recovers the :"more stuff." He may discover "more stuff" contains some digital money :for his troubles, instructions on how much latency (number of :messages, for example) to use, and where to send the resulting packet. :All kinds of stuff can fit in here. But that's not the point. : :If Alice wanted to send a message to Zeke, through a bunch of :remailers, she might create this initial message: : :(Bob (Charles (Doris (Ed (........ (Zeke (final stuff))))....))) [Lots of stuff removed] : :Well, enough for now. There could be some fatal flaws, but this is the :direction I've been thinking about. Eric Messick and Hugh Daniel had :some ideas about "onions" about a year ago, but I never fully grokked :--Tim May : : : :-- :.......................................................................... :Timothy C. May | Crypto Anarchy: encryption, digital money, This will not work if Yancy is not trustworthy. She could then send the message through a chain of compromised remailers, to create the prepaid mailer packet. This would also happen, though less harmfully, any time the chain hit a bad node. Letting the nodes choose the other nodes is fatal. ---------------------------------------------------------- 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 ----------------------------------------------------------

2 1

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

Digital blackboards
by kevin＠axon.cs.byu.edu 17 Dec '03

17 Dec '03

Tim May writes: > Thanks for the comments! And, again, I really wish we had some > blackboards to iron out some details and fix whatever flaws pop up. Those with draw programs conveniently available might want to consider creating diagrams to accompany their articles and posting the postscript along with the article. ----------------------------------------------------------------------------- Kevin S. Van Horn | It is the means that determine the ends. kevin(a)bert.cs.byu.edu |

1 0

Re: GUI for a remailer!
by nate＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

writes Nick Szabo: >Can you post a brief description of how this works for us >Mosaic-deprived souls? > Sorry for the brevity of the announcement, I had just finished it and needed to get to class ;-) OK, I'll start from the beginning (pardon if this is too much info). NCSA has a product (available for Xwindows, MS Windows, and the Mac) called Mosaic. It is a HyperText client (server if your in X, I suppose) that lets the user graphically connect to Gopher, WAIS, and many other already-established information servers (including ftp). The big advantage, however is that it can connect to machines running a WWW server, the most popular, and functional I might add, of these servers is the "HTTPD" server from NCSA itself. It's a long story, but httpd stands for HyperText Transfer Protocol Daemon. Anyway, check with NCSA for more info on httpd. HTTPD 1.0 allows the use of "forms" where I can program in (with extreme ease) text boxes, check boxes, radio buttons, menus, selectable lists, etc. One the other end, the client (Mosaic) interprets this, and will let the user fill out the form and submit it. On my end, a little program catches a stream of data coming from the "world out there" and decodes it so that I can pick out what the user typed into the text boxes, which check boxes are checked, etc... it's quite cool and very easy. The decoding of the data is not really difficult, especially since NCSA provides some functions that will decode it into an array of structures with fields called "name" and "val" -- it's pretty straight forward. My form takes what a user types into the TO: and SUBJECT: boxes, checks to see that the TO: box is not empty and that it has a more-or-less correct email address in it (it checks for an '@' in the value). It then creates a temp file, writes some generic info into it, adds the text from the text box, and makes a system call to mail off the file and destroy it. I coded the whole thing up in about 30 minutes this afternoon. I will be adding check boxes to bounce the mail throught remailers and to do encryption for remailers. I will also add the ability to send mail through anon.penet.fi. For the password to anon.penet.fi, I will use a feture wchich allows the text written in a field to show up as asterics (just for those paranoids out there ;-) As for absolute security, you would just have to trust that I will not be archiving these messages, etc, which I will not. Also, the Mosaic server has the ability to log the IP address from which the connection comes, but as yet, it has no way of figuring out the login name of the person on the other end. Incidently, this whold thing has some *really* cool possibilities. The new HTTPD (1.x) allows for user authentication via passwords -- each directory can have an associated password and group databse... just think of having authentication systems that will let "strangers" send mail in this manner and do all kinds of things virtually anonymously. I really must applaud the NCSA folks for coming up with this, as it has more possibilities that they could have ever dreamt of (which is, I suppose, the mark of really good software). For people wishing to start up their own remailers, even if they don't have access to a machine to make the server, if your site has a server, ask your administrator about "user directories" -- this is where the server has a specified directory that goes in a user's home directory into which users can dump HTML documents (HyperText Markup Language)... for instance, on my server, the directory is called "mosaic-public" so if I have a reference to "http://monet.vis.colostate.edu/~nate/testing.html" then the server figures out that it is actually a link to the file ~nate/mosaic-public/testing.html -- very cool, and actually damn easy for a server admin to set up. Fee free to ask questions. -nate -- +-----------------------------------------------------------------------+ | Nate Sammons <nate(a)VIS.ColoState.Edu> <nate(a)yuma.ANCS.ColoState.Edu> | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+

1 0

Re: Remailing TO anon.penet.fi?!
by Hal 17 Dec '03

17 Dec '03

I set up my remailer on hfinney(a)shell.portal.com to block the password address at anon.penet.fi just so nobody could set a password. I also set a nickname, something like "cypherpunks anonymous remailer". I did this some time ago but I think it is still active. So you can remail at least from my remailer to anon.penet.fi. Hal

1 0

Quantum cryptography
by jito＠netcom.com 17 Dec '03

17 Dec '03

Does anyone know how quantum cryptography works? - Joi -- true name: <Joichi Ito> closest email address: <jito(a)netcom.com> closest fax number: <+81-3-5454-7218> current physical location: <Tokyo> travel path: <.> mosaic home page: http://iikk.inter.net/ -- finger jito(a)netcom.com for PGP Public Key, RIPEM Public Key --

1 0

Re: remailing T anon.penet.fi
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

Hal wrote, "I set up my remailer on hfinney(a)shell.portal.com to block the password address at anon.penet.fi just so nobody could set a password. I also set a nickname, something like "cypherpunks anonymous remailer". I did this some time ago but I think it is still active. So you can remail at least from my remailer to anon.penet.fi. " This isn't as good as getting a password and tagging it ON to mail sent to anon.penet.fi by your remailer, since in a minute I could fake mail to anon.penet.fi from a remailer address to password(a)anon.penet.fi so only I would know the password thus no one else could mail to anon.penet.fi any more. You CAN telnet to port 25 of anon.penet.fi. -Xenon P.S. I am interested in this too, since Julf nailed me for pumping up to two megs through his remailer a day, but I still get one or two "Bomb me!" requests a day for which I ONLY have the person's anon.penet.fi address.

1 0

Five remailers needed NOW. Yo.
by an48138＠anon.penet.fi 17 Dec '03

17 Dec '03

I have played with the Cypherpunk remailers and it turns out it would be very EASY for me to chain my remailing of the five 20-45K messages that I am sending to anyone sending mail to na38138(a)anon.penet.fi with subject "Bomb me!". But it would NOT be easy for me to randomly chain them, two mailers at a time. I don't know perl. I only discovered that if I put long Unix command lines into a file and chmod u+x on it, I can use rsh to remotely execute those commands and pass an environment variable containing the person's address at the same time. I do not want to fully automate it, as one keystoke after highlighting the person's address is easy enough. But I still ask, which five or less remailers should I use. I want fast and very reliable sites, to avoid people receiving a partial mailing and sending me back complaining about it. This would become regular and confusing if the delay between the parts was great. I could add a header explaining this to them though. If you care enough, you could mail me a script that would output ten randomly seleted remailer addresses and I could use those variables in my mailer command file. Then I would be sending to five random sites and these would chain to a second random site and be sent to their final destination. Again, I am not very interested in using encryption, period. Thanks. -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

REMAIL: Cover traffic
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

>> It has also been suggested that "bit-bucket" addresses, people who >> would receive messages from the network and discard them, would help. Consider that a number of "bit-bucket" addresses already exist -- to exploit them, all you have to do is include the name of a particular account in the midwest, whose mail is already automatically filtered out by a vast number of cypherpunks readers :-)

1 0

Re: Remailers needed. My survey.
by nobody＠eli-remailer 17 Dec '03

17 Dec '03

Eli wrote, "I just ran a few tests, bouncing umass.edu -> remailer -> umass.edu for sizes up to 55K. Round-trip time was 3 to 4.5 minutes, uncorrelated with message size. (Bottlenecks are the jarthur outgoing queue, and some baroque hand-off job within umass.edu) What sort of timings were "way too slow"?" I just tried it again and your remailer needs to be added to the "Very fast" list! Not sure what happended the first time. By "Very fast" I mean I get something back in less than a minute or two. By "Way too slow." I mean I just never really saw it come back. I would classify anon.penet.fi as "Way too slow" as I cannot even cooperate on a mailing list with its upwards of 6-24 hour delays. That leaves, 1 nowhere(a)bsu-cs.bsu.edu <-[Way too slow.] 1 remail(a)tamsun.tamu.edu <-[Way too slow.] I'm still waiting and waiting and.... I tried these again, with no typos, and it's been 45 minutes. Gary checked these for the FAQ so they must work. Could be certain sites are down along the way. I have some OLD logs of my playing with these, and at least once they got a "fast" rating. The problem is, I'm new to these remailers so if one fails ONCE I don't know what to think. -Xenon P.S. I still need a perl (or whatever) script to output ten variables containing a random assortment of remailer addresses. These need to be csh environmental variables. This is only because I have a little commands file that uses such variables. I know if I knew perl I could whip this up in 5 minutes, so could somebody spend 5 and post this, and tell me how to run it. Thanks.

1 0

hh@cicada.berkeley.edu has died.
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

hh(a)cicada.berkeley.edu stopped sending me things back. I at most sent five 46K files in a row. Did I break it? Or did the ethernet cord drop off the back of the MacPlus ;-)? Really, I have no idea what these remailers are running on. -Xenon

1 0

dongle redux redux
by peace＠BIX.com 17 Dec '03

17 Dec '03

ccat(a)netcom.com (Chris Beaumont)> I think the idea of a standard user configurable crypto-engine is a good one..that way people could choose (and upgrade) algorythms.. sort of like modern DSP based highspeed modems..(It could also have a socket for ROM based firmware cartridges..(RSA,IDEA,etc..) and a magstripe reader and keyboard for key entry..(This would make trading keys easy..) ViaCrypt now sells three versions of a security module, one on a dongle for a parallel port, another on a serial port, that can do all the interesting crypto algorithms of the day. And all are fully licensed. Send your snail mail address for glossies. Peace

1 0

HTTP 1.1 and Mosaic 2.2 support PEM/PGP authentication
by remailer＠merde.dis.org 17 Dec '03

17 Dec '03

FLASH: HTTP 1.1 and Mosaic 2.2 support PEM/PGP Authentication Mosaic Pages for http 1.1 for PEM/PGP auth http://hoohoo.ncsa.uiuc.edu/docs/ Using PGP/PEM encryption This document is formatted roughly like a FAQ. Here are the section headings: What is PGP/PEM encryption? How are they used in HTTP? What do I need to use it? How do the keys get distributed? How bulletproof is it? Installation: server side. Installation: client side. What does the protocol look like? What is PGP/PEM encryption? PGP and PEM are programs to allow you and a second party to communicate in a way which does not allow third parties to read them, and which certify that the person who sent the message is really who they claim they are. PGP and PEM both use RSA encryption. The U.S. government has strict export controls over foreign use of this technology, so people outside the U.S. may have a difficult time finding programs which perform the encryption. How are they used in HTTP? We have implemented a system by which NCSA Mosaic and NCSA httpd call external programs which encrypt and decrypt their communications and thus provide secure communications between the server and the client and ensure that a user is who he/she says they are. This system currently has hooks for PEM encryption as well as PGP encryption. As interest in this area grows, more will most likely be added. What do I need to use it? You will need a working copy of either Pretty Good Privacy or RIPEM to begin with. You should be familiar with the program and have generated your own public/private key pair. You should be able to use the TIS/PEM program with the PEM authorization type. I haven't tried it. This tutorial is written assuming that you are using RIPEM. How do the keys get distributed? Currently, we have implemented this protocol with PEM and PGP using local key files on the server side, and on the client side with PEM using finger to retrieve the server's public key. As you can tell, parties who wish to use Mosaic and httpd with PEM or PGP encryption will need to communicate beforehand and find a tamper-proof way to exchange their public keys. How bulletproof is it? Pioneers get shot full of arrows. This work is currently in the experimental stages and thus may have some problems that I have overlooked. There aren't any that I can see but I've been looking at it for a long time. There may be some quirks in the additions to Mosaic and httpd as well. In particular, error recovery is not always as helpful as it could be. The only known problem that I know about is that the messages are currently not timestamped. This means that a malicious user could record your encrypted message with a packet sniffer and repeat it back to the server ad nauseum. Although they would not be able to read the reply, if the request was something you were being charged for, you may have a large bill to pay by the time they're through. Installation: The Server Side First, you must compile httpd with CFLAGS set to -DPEM_AUTH. This will enable the PEM and PGP authentication directives. Next, look in the support/auth directory. This directory contains your encryption and decryption scripts, as well as bins for your remote users' public keys. Edit ripem-dec, ripem-enc, pgp-enc, and pgp-dec and follow the instructions therein. You need not set up PGP if you don't plan to use it, and same with RIPEM. Now, edit your server configuration file, usually conf/httpd.conf. You will want to add three new directives for PGP and three new directives for PEM depending on which you plan to use (or both). PEMEncryptCmd /usr/local/etc/httpd/auth/ripem-enc PGPEncryptCmd /usr/local/etc/httpd/auth/pgp-enc These directives change what executables httpd will look for when it is trying to encrypt its reply to a client. Edit the pathnames to taste. PEMDecryptCmd /usr/local/etc/httpd/auth/ripem-dec PGPDecryptCmd /usr/local/etc/httpd/auth/pgp-dec These directives change what executables httpd will look for when it is trying to decrypt the client's request. PEMServerEntity webmaster(a)foobar.org PGPServerEntity webmaster(a)foobar.org These directives set your entity name. This should be the same as the name you place on the public/private keys you generate for your server. If you make these directives different than the key names, your server and its client will become hopelessly confused. You are now ready to protect directories of your server with this authorization scheme. For a directory you want to protect, you should first set its AuthType. Use AuthType PGP for a directory you are protecting with PGP and AuthType PEM for a directory you are protecting with PEM. The require directive accepts key names as its arguments. The AuthGroupFile directive is valid as well, to create groups of keys. A full example: AuthType PEM AuthGroupFile /httpd/.htgroup-pem Options None <Limit GET> require user robm(a)ncsa.uiuc.edu require group pemusers Let's say /httpd/.htgroup-pem reads: pemusers: pls(a)ncsa.uiuc.edu In this case, this directory will be protected with PEM encryption and will require that only users robm(a)ncsa.uiuc.edu and pls(a)ncsa.uiuc.edu be allowed to access that directory. Installation: the Client Side First, get a copy of Mosaic/X 2.2. If it hasn't been released yet, be patient. Compile it with -DPEM_AUTH to enable PEM/PGP authentication. Follow the instructions in each of the scripts in the auth subdirectory to customize them to your setup. There are six new X resources which have been defined for PEM/PGP authentication. They are: Mosaic*pemEncrypt: /X11/robm/Mosaic/auth/ripem-enc Mosaic*pemDecrypt: /X11/robm/Mosaic/auth/ripem-dec Mosaic*pemEntity: robm(a)ncsa.uiuc.edu Mosaic*pgpEncrypt: /X11/robm/Mosaic/auth/pgp-enc Mosaic*pgpDecrypt: /X11/robm/Mosaic/auth/pgp-dec Mosaic*pgpEntity: robm(a)ncsa.uiuc.edu You should change the Encrypt and Decrypt entries to reflect where you are going to install your encryption and decryption crypts. You should change the Entity lines to the key name you have given the server maintainers for yourself. If you don't, bad things will happen. What does the protocol look like? This protocol is almost word-for-word a copy of Tony Sander's RIPEM based scheme, generalized a little. Below, wherever you see PEM you can replace it with PGP and get the same thing. Client: GET /docs/protected.html HTTP/1.0 UserAgent: Mosaic/X 2.2 Server: HTTP/1.0 401 Unauthorized WWW-Authenticate: PEM entity="webmaster(a)hoohoo.ncsa.uiuc.edu" Server: NCSA/1.1 Client: GET / HTTP/1.0 Authorized: PEM entity="robm(a)ncsa.uiuc.edu" Content-type: application/x-www-pem-request --- BEGIN PRIVACY-ENHANCED MESSAGE --- this is the real request, encrypted --- END PRIVACY-ENHANCED MESSAGE --- Server: HTTP/1.0 200 OK Content-type: application/x-www-pem-reply --- BEGIN PRIVACY-ENHANCED MESSAGE --- this is the real reply, encrypted --- END PRIVACY-ENHANCED MESSAGE --- That's it. Almost all of this stuff is my fault (including the implementations), so direct comments about it to me. Rob McCool, robm(a)ncsa.uiuc.edu

1 0

Digital Cash....
by Jim choate 17 Dec '03

17 Dec '03

Has anyone looked at basing digi-cash on the processing power required to handle it? In other words, instead of basing it on real cash directly or simply setting up a 'flat' standard (is there an accepted technical term for this?) base it on the MIPS that are required to process it in a given time (say 1mS)? Seems to me that this would provide a standard that was universal and verifiable by any organization that chose to spend the effort to do it. It would also add another layer of isolation (since the only person (sic) involved w/ real cash is going to the be processing sight paying their electric bill).

1 0