December 2003 - cypherpunks-legacy

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

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

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