December 2003 - cypherpunks-legacy

Re: a protocol (that doesn't work)
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Did you ever wish there was an "unmail" command? I realized about halfway home that the protocol I described not only didn't work, but demonstrated to the world my lack of understanding of the man-in-the-middle attack against Diffie-Hellman. Oh well, I guess I'll keep my day job a little longer... At least I now have a better understanding of just how hard it is to foil man-in-the-middle attacks. >From reading the description of the Interlock Protocol, I saw that it is possible to arrange things so the man in the middle has to do a lot more work. It may be that Robert Cain has come up with a protocol that increases the work necessary to maintain a man-in-the-middle attack to the point where the attack becomes impractical, although not impossible, in theory. However, I think that is this becomes the case, an attacker would simple cut Bob completely out of the picture and change the man-in-the-middle attack to a %100 spoof of Bob. Since Alice and Bob have never met and don't share any secrets, how would Alice be able to tell the difference between the real Bob, and Mallet completely spoofing Bob? In the abstract, I don't see any way. There may be some real-world situations where Alice can tell the difference between Bob and pseudo-Bob. It depends on the situation and what assumptions Alice makes about a properly behaved Bob. If pseudo-Bob doesn't behave the way Alice expects real-Bob to behave, then Alice could get suspicious. But now we've existed the realm of cryptography and enter the realm of human relations. Of course, there's still a lot of money to be made offering imperfect solutions that are good enough for some people. Jim_"still learning"_Miller(a)suite.com

1 0

REMAIL: list of remailers
by Karl Lui Barrus 17 Dec '03

17 Dec '03

Well, it's been a bit since I posted this, I hope I got all the activity over the past month. -----BEGIN PGP SIGNED MESSAGE----- Cypherpunk anonymous remailers, 2/13/94 Q1: What are the anonymous remailers? A1: 1: remailer(a)chaos.bsu.edu 2: nowhere(a)bsu-cs.bsu.edu 3: hh(a)cicada.berkeley.edu 4: hh(a)pmantis.berkeley.edu 5: hh(a)soda.berkeley.edu 6: 00x(a)uclink.berkeley.edu 7: hal(a)alumni.caltech.edu 8: ebrandt(a)jarthur.claremont.edu 9: catalyst(a)netcom.com 10: qwerty(a)netcom.com 11: remailer(a)rebma.mn.org 12: elee6ue(a)rosebud.ee.uh.edu 13: elee7h5(a)rosebud.ee.uh.edu 14: hfinney(a)shell.portal.com 15: barrus(a)tree.egr.uh.edu 16: remailer(a)utter.dis.org 17: remailer(a)entropy.linet.org 18: elee9sf(a)menudo.uh.edu 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 11,16,17,19 introduce larger than average delay (not direct connect) 11,16,19 running on privately owned machines 18 supports RIPEM encryption, caches remailing requests 15 supports different request syntax 5 features USENET posting ====================================================================== 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 For MAC's, at 129.82.156.104 in /pub/pgpc/ are two files: pgpc22.tar.gz, pgpc22.tar.Z which assist in using the anonymous remailers, including anon.penet.fi. Or try the cypherpunks gopher site (chaos.bsu.edu) and look in "Anonymous Mail" for instructions. 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. * Remember to include a Subject: with your post, may cause failures if missing #6 blocks from non-berkeley sites (so use the berkeley remailers :-) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLV6YtoOA7OpLWtYzAQFwogQAxfy0wgSBBDtFXCMoI6ie1cTJSlw8kPrz wCKwsVN5gOrIIjCiesfbcQCwJYOyQMvOFfem3AI7M/fhKWocObqca8h5dViXi21O ZKXzZM2QeKmlNI35OwpgxUSp6hZa6rI8xJxvG88yadCZ0oNisvz5Ibb0Pab3XH1p 3nk0upVKlSM= =VnOr -----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

Unsubscribe me!
by K12OCEZB＠vaxc.hofstra.edu 17 Dec '03

17 Dec '03

Begging your apologies but I tried unsubscribing on Friday and I'm still getting mail, so please, Unsubscribe Evan Boshnack Do what needs to be done to "make it so" Thanx, Evan

3 2

No Subject
by Anonymous 17 Dec '03

17 Dec '03

While not _directly_ an encryption matter, it bears pointing out that pure text seems to be falling under the tender ministrations of the Bureau of Alcohol, Tobacco and Firearms. Reports in talk.politics.guns indicate that the Louisville, KY BATF has informed a non-FFL (i.e., not a gun dealer, thus not under BATF jurisdiction in the matter) Army-Navy store's proprietor that it would be "shut down" if he did not remove from sale some Paladin Press titles on illegal conversion of firearms. According to followups, it's worse: The State of Michigan has outlawed such texts for some time now.

1 0

Setting up a Magic Money server
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Magic Money seems to have reached a usable state. (Open mouth, insert foot, bite down firmly :-) ) Someone needs to set up the first server. Here's how: You can set up a Magic Money server on any machine with a net connection. You need to be able to run a program when mail comes in. You do not need root access. Running a Magic Money server is no harder than running a cypherpunks remailer. Unlike a remailer, there is no possibility of your server being used to harass or mailbomb anyone. Get Magic Money and PGP Tools (needed to compile it) from csn.org. Get pgptl10c.zip and mgmny10e.zip. If mgmny10e.zip isn't up yet, get mgmny10d.zip and fix the bug in mms_mint() by moving the free(fp); to the end of the function. This is the only change in version e. This version has been reported to work on both big and little endian machines. If your machine has assembly-language speedups, get them from the pgp23a source code. Use the same defines PGP uses to compile on your machine, and take out the NO_ASM define in my makefile. This will speed up your server quite a bit. Compile the client and the server. Define UPTON or one of the other modmult functions, because I have had problems with Smith's modmult. The hash file is currently set to about half a meg. It grows if it fills up. If you need to use less disk space, change the settings in mm.h. Put the server program "s" in one directory, and the client program "c" in another. Put something random (i.e. unknowable to an attacker) in a file called rand.dat in each directory. The programs won't work without this. The directories should be otherwise empty. Go to the server directory and run "s i" to initialize the server. It will ask you for the name of your server, size of your key, name of your coins, and denominations to use. Powers of 2 make good denominations. For example, you might use 1,2,4,8... up to 32768. With these 16 coin values, you can transfer any sum up to 65535 with 16 or fewer coins. After you have entered all the information, the server generates a PGP key pair, and an e/d list pair. Your server's ascii-armored public key is saved to bank.asc. You will need to distribute this key to everyone who wants to use your server. Copy bank.asc into the directory with the client. In that directory, run "c -i" to setup the client. The client generates a key, then creates a message "output.asc" which should be sent to the server. For example, if "client" and "server" were subdirectories in a common directory, you could run "s < ../client/output.asc > ../client/reply.asc" from the server's directory. Now go back to the client directory and run "c reply.asc" to finish setting up your client. You will be running this sequence a lot if you play with the system, so write a script. Your client now knows the name of your coins, and has the elist. This information is updated automatically when the server discovers the client's copy is out of date. Go back to the server directory and run "s m <x>" where x is one of your higher-value coins. You will have problems if you are using version d and did not fix the bug as described above. This mints a coin and writes it out to coins.dat. Go back to the client directory and run "c ../server/coins.dat". The client reads the coin, checks it, and asks you for values of new coins to create. Create several smaller coins. The client keeps prompting you until you have created coins with a value equalling that of the old coin. The client creates another "output.asc". Run your script to pass it through the server, and run "c reply.asc" to process the results. The client now takes the signed coins from the server and the blinding factors from proto.dat, and unblinds the coins. The result is written to allcoins.dat. Now run "c -p" to withdraw coins from allcoins.dat. Enter the denominations to withdraw, and 0 to end. Now you have a coins.dat in the client's directory, so run "c coins.dat" to process it. It will count up the coins you withdrew, and prompt you for new coin values again, then produce another output.asc for the server. You can create a second client in another directory, and pass coins from one to the other. Try creating a "msg.txt" file in the server's directory. The client will then display the contents of the message whenever it processes a reply from the server. The client waits for a keypress after the message. Now that you know the server works, set it up so that incoming mail to your account is passed to the server, and the output from the server is sent back to the person who sent the mail. If you want to use the same account for the server and regular mail, have users put a specific word in the subject line of messages to the server. Announce your server, including its public key from bank.asc. You might want to provide binaries of the client for DOS, either by ftp or by automatic mail. You might also want to write a better makefile for the Unix version. Now you need to mint and distribute some, but not too much, money for people to play with. Give a few coins to the first x people who send a message to your system. Later you can have lotteries, post puzzles and simple ciphers for people to break, etc. to put more money into circulation. But keep your money scarce. People should be able to get a few coins to play with, but they should always want more than they have. Good luck! Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVyldMGoFIWXVYodAQGo4AP/SQz82XRtWC1W/qjGQWouVDn/82TBBGne ktNIfmPE92lPpH0V3f7EizBs466AEXTwaxq5qVpj4Fx6low1ceiaKBQxhNosB8Wa BydiS2E2iC6kQ1RPj5jb6UOdLTQzl2MM7UrI8J3KpxszQWjhbgM/5ddHoDXgqs/J VjjeM/iqNF8= =2ggl -----END PGP SIGNATURE-----

1 0

Setting up a Magic Money server
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Magic Money seems to have reached a usable state. (Open mouth, insert foot, bite down firmly :-) ) Someone needs to set up the first server. Here's how: You can set up a Magic Money server on any machine with a net connection. You need to be able to run a program when mail comes in. You do not need root access. Running a Magic Money server is no harder than running a cypherpunks remailer. Unlike a remailer, there is no possibility of your server being used to harass or mailbomb anyone. Get Magic Money and PGP Tools (needed to compile it) from csn.org. Get pgptl10c.zip and mgmny10e.zip. If mgmny10e.zip isn't up yet, get mgmny10d.zip and fix the bug in mms_mint() by moving the free(fp); to the end of the function. This is the only change in version e. This version has been reported to work on both big and little endian machines. If your machine has assembly-language speedups, get them from the pgp23a source code. Use the same defines PGP uses to compile on your machine, and take out the NO_ASM define in my makefile. This will speed up your server quite a bit. Compile the client and the server. Define UPTON or one of the other modmult functions, because I have had problems with Smith's modmult. The hash file is currently set to about half a meg. It grows if it fills up. If you need to use less disk space, change the settings in mm.h. Put the server program "s" in one directory, and the client program "c" in another. Put something random (i.e. unknowable to an attacker) in a file called rand.dat in each directory. The programs won't work without this. The directories should be otherwise empty. Go to the server directory and run "s i" to initialize the server. It will ask you for the name of your server, size of your key, name of your coins, and denominations to use. Powers of 2 make good denominations. For example, you might use 1,2,4,8... up to 32768. With these 16 coin values, you can transfer any sum up to 65535 with 16 or fewer coins. After you have entered all the information, the server generates a PGP key pair, and an e/d list pair. Your server's ascii-armored public key is saved to bank.asc. You will need to distribute this key to everyone who wants to use your server. Copy bank.asc into the directory with the client. In that directory, run "c -i" to setup the client. The client generates a key, then creates a message "output.asc" which should be sent to the server. For example, if "client" and "server" were subdirectories in a common directory, you could run "s < ../client/output.asc > ../client/reply.asc" from the server's directory. Now go back to the client directory and run "c reply.asc" to finish setting up your client. You will be running this sequence a lot if you play with the system, so write a script. Your client now knows the name of your coins, and has the elist. This information is updated automatically when the server discovers the client's copy is out of date. Go back to the server directory and run "s m <x>" where x is one of your higher-value coins. You will have problems if you are using version d and did not fix the bug as described above. This mints a coin and writes it out to coins.dat. Go back to the client directory and run "c ../server/coins.dat". The client reads the coin, checks it, and asks you for values of new coins to create. Create several smaller coins. The client keeps prompting you until you have created coins with a value equalling that of the old coin. The client creates another "output.asc". Run your script to pass it through the server, and run "c reply.asc" to process the results. The client now takes the signed coins from the server and the blinding factors from proto.dat, and unblinds the coins. The result is written to allcoins.dat. Now run "c -p" to withdraw coins from allcoins.dat. Enter the denominations to withdraw, and 0 to end. Now you have a coins.dat in the client's directory, so run "c coins.dat" to process it. It will count up the coins you withdrew, and prompt you for new coin values again, then produce another output.asc for the server. You can create a second client in another directory, and pass coins from one to the other. Try creating a "msg.txt" file in the server's directory. The client will then display the contents of the message whenever it processes a reply from the server. The client waits for a keypress after the message. Now that you know the server works, set it up so that incoming mail to your account is passed to the server, and the output from the server is sent back to the person who sent the mail. If you want to use the same account for the server and regular mail, have users put a specific word in the subject line of messages to the server. Announce your server, including its public key from bank.asc. You might want to provide binaries of the client for DOS, either by ftp or by automatic mail. You might also want to write a better makefile for the Unix version. Now you need to mint and distribute some, but not too much, money for people to play with. Give a few coins to the first x people who send a message to your system. Later you can have lotteries, post puzzles and simple ciphers for people to break, etc. to put more money into circulation. But keep your money scarce. People should be able to get a few coins to play with, but they should always want more than they have. Good luck! Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVyldMGoFIWXVYodAQGo4AP/SQz82XRtWC1W/qjGQWouVDn/82TBBGne ktNIfmPE92lPpH0V3f7EizBs466AEXTwaxq5qVpj4Fx6low1ceiaKBQxhNosB8Wa BydiS2E2iC6kQ1RPj5jb6UOdLTQzl2MM7UrI8J3KpxszQWjhbgM/5ddHoDXgqs/J VjjeM/iqNF8= =2ggl -----END PGP SIGNATURE-----

1 0

escrow-to-black box protocol
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Has the government published a description of the protocol the escrow agencies will use to download the Clipper keys to the black boxes? If so, is there a FTP'able description of it somewhere? Jim_Miller(a)suite.com

1 0

T.C.May `forgery'
by L. Detweiler 17 Dec '03

17 Dec '03

Cypherpunks, I did not write that letter. It was fowarded to me via an anonymous remailer. One among you sent it to me. The question is, which one? why? To those of you who are so confident it is a forgery-- why? perhaps it is, but you base your dogmatic convictions on nothing credible, simply your passionate, zealous enmity to me. BTW, this is my official resignation as Chief Cypherpunk Whistleblower. The position is a thankless, nasty job. There just really is no place for me in cyberspace.

1 0

REAL WORLD ENCRYPTION
by Sandy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, I would like to start a new thread. I want to know what the people on this list intend to do with cryptography in the "real world." There are a number of Cypherpunk projects on the drawing board or already deployed: Stego, encrypted phones, encrypted and anonymous remailers, stealth PGP, a digital bank, etc. Do the folks on this list intend to use these tools, or is your interest only theoretical? I'm not looking for simple "yes" or "no" comments, however. I'm interested in finding out how much you are willing to reorganize your life in order to take advantage of these techniques. I want to know what factors would increase or decrease your use of cryptographic products and services. What do you want? What do you fear? My interest is more than academic. I am one of the Cypherpunks involved in creating a digital bank. If the 700 or so people on this list wouldn't open an account in a digital bank, chances are no one else would either. The same goes, of course, for secure phones, encrypted e-mail, and all the rest. What Real World concerns you have about crypto? Talk to me. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLV65Ek5ULTXct1IzAQHpBQP/aaCxIpmSZru4viy43hsK0Z9jdkjCw0zm S89ZhTP7w2nJkBqUT0qzOi0N42yTAaxL77fLDTeiRrBkAlgmEZDMeYEf7em4rAa3 yDmhkMd4yhgReDr+hNKl7OhvHL776An7STJ4pJAbdbKAipLAFNAF4lTcT5Ucf14h 1WXFBQklrv8= =tS11 -----END PGP SIGNATURE-----

5 4

Spread encryption with telnet?
by Jonathan Corbet 17 Dec '03

17 Dec '03

The current furor over people with password sniffers on the Internet made me think of another possible option for spreading the use of encryption on the net. As everbody knows, the problem is with the passing of plaintext passwords over the net. Get rid of these passwords, and the crackers have to go back to the other 99999 ways of breaking into machines. It couldn't be very hard to grab a version of telnet and telnetd off the net and hack in some sort of encryption of the data stream. Heck, you could just use the vendor's DES library on systems that have it -- perhaps not the most aesthetic solution, but easy. Put in a negotiation option so that encryption will be used when both ends support it, and you have instant plug-in relatively secure telnet. As a bonus, you get your whole session encrypted, not just the password. It seems like it could be much easier to install than, say, kerberos, and offer more security. I would guess that if you made something like this available and EASY, that lots of people would install it on their machines. Folks are a little nervous right now, and a sniff-proof telnet might make them feel better. If I made a telnet that simply hooked into a vendor's encryption library, with no internal encryption code, would I have ITAR problems still? That may be moot, since any vendor encryption library almost certainly will not address the problem of coming up with a session key, so probably some sort of key exchange protocol would have to be put in. Overall, this seems easy and useful enough that I'm amazed that nobody has done it yet. Have I missed something? jon

3 2