December 2003 - cypherpunks-legacy

Re: List of forbidden mathematics?
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

> Do any of you have a current list of banned mathematics topics handy? > I was reading a number theory book (Rosen) and got worried that I > might be stumbling into some of the areas forbidden to private > citizens. Are these topics forbidden by law or by influence? Hadmut

1 0

DELETE ME FROM THIS MAILING LIST
by BOBES_PIERRE＠delphi.com 17 Dec '03

17 Dec '03

Sorry to take up bandwidth; but I have tried the proper procedure for signing off this list to no avail. Please do sign me off. thanks bob

1 0

forbidden mathematics (I got the joke now...)
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

Thanks to all for showing me that it was a joke only. :-) I didn't have the context and was taking this as strange but serious. It is sometimes very difficult to distinguish between satire and law. Hadmut ( a little bit slow with everything today...)

1 0

Re: Strategies for getting encryption in widespread use QUICKLY
by Pat Farrell 17 Dec '03

17 Dec '03

In message Sat, 12 Feb 94 11:11:09 MST, Bryan Ford <baford(a)schirf.cs.utah.edu> writes: > This is another good application, but I think it suffers from the same > problem as encrypted E-mail messages: as long as it's even a little > less convenient than no encryption, most people just won't care enough > to use it. I agree completely with this. we have to move encryption onto the desktop PCs and Macs, and make it transparent to the naive users. Eudora and NUpop are a good start, but aren't transparent when you use PGP or ViaPGP. I've written a non-TCP/IP Windows POP/SMTP client that will work with commercial providers such as Netcom and Digex, but I can't get the low level communications code to work - Window's comm.drv API is too flakey for me to understand and get working. I believe that my code is less than a week or two from being ready to distrubute, if I can get some help with the communications code. I asked a few months ago, and had one volunteer who didn't deliver. I'd love to find a cypherpunk willing to work with me to provide some sorely needed enabling technology. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

2 1

They`re Baaaaack!
by Duncan Frissell 17 Dec '03

17 Dec '03

For the second week in a row; the Admin, fascism, and computers made the front page of the Saturday NYT. "U.S. Seeks Wiretap Software for Law Enforcement" They are going to legislate the Digital Telephony Initiative or the kinder, gentler, version thereof. Telecoms customers will get to pay $300+ million to tap themselves. The Klinton proposal is alleged to be mellower than Bush's because it exempts "private networks." That means it's meaningless since virtually all future voice and data services will be delivered over "private networks." DCF "But the President of the United States *is* named Schicklgruber." -- Firesign Theater Liberation Front --- WinQwk 2.0b#1165

1 0

a protocol
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

An idea came to me today for a protocol for exchanging keys point-to-point (inspired by the Robert Cain messages). The protocol is a just combination of the Interlock Protocol described on page 44 of "Applied Cryptography" and Diffie-Hellman, describe on page 275. Keeping with the terminology of the book, Alice will attempt to exchange a key with Bob, and Mallet will attempt to sit in the middle without being detected. As has been demonstrated in the past, I haven't read a lot of the cryptography papers that are out there, so for all I know, this is a well known protocol (or simple variation). However, I haven't seen it, and it seems interesting. Anyways, on with the show... 1) Alice sends Bob her public key. (ala Interlock Protocol) 2) Bob sends Alice his public key. 3) Alice generates a Diffie-Hellman "n" value, encrypts "n" with Bob's public key and sends half of the "n" message to Bob. 4) Bob generates a Diffie-Hellman "g" value, encrypts "g" with Alice's public key and sends half of the "g" message to Alice. 5) Alice sends other half of "n" message to Bob. 6) Bob puts the two halves of Alice's "n" message together and decrypts it with his private key. Bob sends the other half of his "g" message to Alice. 7) Alice puts the two halves of Bob's "g" message together and decrypts it with her private key. Alice and Bob's each now have an "n" and a "g". Below, I try to show that they can only have the same "n" and "g" if there is no man-in-the-middle. Alice chooses a random large integer x and computes: X = (g**x) mod n Bob chooses a random large integer y and computes: Y = (g**y) mod n Standard Diffie-Hellman stuff. 8) Alice encrypts X with Bob's public key and sends half of X message to Bob. 9) Bob encrypts Y with Alice's public key and sends half of Y message to Alice. 10) Alice sends other half of X message to Bob. 11) Bob puts the two halves of Alice's X message together and decrypts it with his private key. Bob sends the other half of his Y message to Alice. 12) Alice puts the two halves of Bob's Y message together and decrypts it with her private key. Now Alice and Bob's each have an X and a Y. Alice computes k = (Y**x) mod n. Bob computes k' = (X**y) mod n. 13) Alice encrypts a message using k and sends it to Bob. Bob decrypts message using k' and validates success of protocol. 14) Bob encrypts a message using k' and sends it to Alice. Alice decrypts message using k and validates success of protocol. ---------- What can Mallet do to this protocol? Mallet can substitute his own public keys for Alice's and Bob's in steps 1 and 2. Mallet can then capture "n" (from Alice) and "g" (from Bob), although not immediately. Mallet forward Bob bogus "n" message halves and Alice bogus "g" message halves. Thus Alice will get a bogus g, call it g', and Bob will get a bogus n, call it n'. Mallet cannot forward the real "n" to Bob because of the interlock protocol. Similarly, Mallet cannot forward the real "g" to Alice. Mallet only learns "n" in step 5 and "g" in step 6. However, he must forward half of a bogus "n" to Bob in step 3), half of a bogus "g" to Alice in step 4. At the end of step 6, Alice will have n and g' and Bob will have n' and g. Alice and Bob continue with the protocol and calculate X and Y. Alice and Bob use the interlock protocol to exchange X and Y. As with n and g, Mallet will eventually get X and Y, but not before having to forward a bogus X to Bob and a bogus Y to Alice (call them X' and Y'). Alice and Bob, still unaware of Mallet, compute k and k'. However, since they are using different values for n, g, X, and Y, they will compute different values. The encrypted messages in steps 13 and 14 will expose Mallet. I've only spent about fifteen minutes thinking about this protocol. I can't say that it is without holes or even that it does what I say it does. However, I think it might have potential. What to the professionals think? Jim_Miller(a)suite.com

2 1

Patches for magicmny
by nobody＠jarthur.Claremont.EDU 17 Dec '03

17 Dec '03

I had to make a few patches for pgptools and magic money to compile on a dos system with microsoft c 6.0. #include <mem.h> and #include <io.h> do not work with this compiler. I added #ifdef __TURBOC__ around these includes in mm.c, s.c, c.c, and ptd.c. In pgpmem.c, this system has malloc.h but not alloc.h. Change the #ifdef MSDOS to #ifdef __TURBOC__. With these changes it worked.

1 0

No Subject
by Anonymous 17 Dec '03

17 Dec '03

Developers using the current version of PGPtools should becareful to add keyspace FIFO and passphrase "burns" to their applications to insure that security critical information is NOT left carelessly in memory... while PGP 2.3A is VERY scrupulous, PGPTools package does NOT have sufficient internal checks and "burns" at present...this is left to the developer at pressent... I also noted a fifo_unlink routine where a burn should be performed prior to the unlink from the FIFO queue... Anon

1 0

How to easily increase remailer traffic
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

Recently I was reading a message about how fast ftp porno sites go down because as soon as they are announced they undergo constant heavy use. Given an anonymous remailer network, there is no need for sending random noise messages to keep a constant traffic. Simply set up a double blind porno e-mail archive site. The site address itself would be a self-addressed pgp remailer block, and all return addresses would be SASE too. Not only would this provide a constant background of data flowing to hide important messages in, but it would also incentivize thousands of people on the net into using pgp via e-mail daily and would educate them about crypto. The double blind mechanism would keep the site safe from direct attack, and would give many people more confidence about requesting such files (since they could be encrypted on delivery) As more sites pop up using the double blind mechanism to avoid discovery, more and more remailers would be added to the network. People would be encouraged to set up simple light-weight remailers in their .forward once they figure out that there is safety in large numbers. Pornography is usually the first media to use new technology. Whether it's modems, networks, bbs, minitel, irc, muds, cd-roms, independent phone service, desktop video, desktop publishing, video games, you name it. Let's harness its power to found cryptoanarchy in cyberspace. All that's needed is a uucp setup, about 20 megs for jpeg picture archive or story archive, pgp, and some slightly more powerful remailer software. This is guaranteed to generate a steady stream of remailer usage (possibly too much) -Ray (unsubscribed still) -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

1 0

Re: Strategies for getting encryption in widespread use QUICKLY
by Pat Farrell 17 Dec '03

17 Dec '03

In message Sat, 12 Feb 1994 13:00:55 -0800, Peter shipley <shipley(a)merde.dis.org> writes: > This is why I email this list to encourage the use of MIME email headers > with a MIME mailer (elm, pine, mh, Zmail etc..) when a person > receives email, the mailer agent will invoke pgp automaticly > thus reading encrypted email is a user transparent process. Clearly MIME is a step in the right direction. And clearly MIME is steg friendly, who can tell a MIME encoded PGP message from a MIME encoded GIF file without looking at character frequencies, etc. (You _know_ that I'm going to lie about the MIME-Content-Type flag :-) But I haven't yet found a Windows PC client that will work without TCP/IP. Maybe I haven't looked hard enuff. Since 85% of all computers are shipped with Windows, "widespread use" means Windows (or Windoze for the cynics). I also don't know why the network vendors charge so much more for SLIP and/or PPP, but until IP is as cheap as async, there is a need for lower technology solutions. There are also some design questions that have to be addressed on the human interface side. For example, some folks strongly prefered not to receive encrypted mail, because they didn't work in an PGP friendly environment. So you need to have a client that is smart enuff to automatically encrypt to folks who control machines on the net, and not encrypt by default to folks using unsecure delivery such as netcom.com's vt100 based users. And you need a nice way to override the default. Clearly this information goes in the roledex that you keep with your client software. I mention it only so that folks realize that the simple publication of a PGP or RIPEM key does not indicate that a user is ready to receive all email encrypted. Solving these problems is exactly why we write code. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

2 1