- cypherpunks-legacy - lists.cpunks.org

Re: PGP automation
by nobody＠cicada.berkeley.edu 17 Dec '03

17 Dec '03

> > secure stuff. Anyone here have any other suggestions on making encryption > > less of a pain? > >This may seem a little excessive, but the only sensible way to use >pgp in environments like yours or prz's (heh heh) is to set yourself >up with your own site at home, either with a dialup SLIP/PPP feed or >a plain and cheap uucp feed. Both of those options are becoming much >cheaper than they used to be, and you can run suitable software on all >sorts of computers - whatever you're using to dial in to your timeshare >service at the moment would probably do, as long as its not just a dumb >terminal. DOS, a free unix or linux, Amiga, Atari - they can all handle >at least uucp if not tcp/ip too. If you don't have suitable hardware, >you can surelu find a 286 dos box with an old 20Mb drive and plain text- >only display secondhand somewhere for $200 or less... that'll run UUPC >or even KA9Q. Why not just get Nupop, a freeware mail downloader, off Simtel? No good for reading newsgroups, but mail, no problem. > >If you care about privacy in your email, you *have* to run it all the >way into your own machine. Agreed.

1 0

Hole in MD5
by Mike Ingle 17 Dec '03

17 Dec '03

Recently there was a message here about MD5 having a hole in it. Maybe this is what the person was talking about... >From msuinfo!uwm.edu!cs.utexas.edu!uunet!ddsw1!chinet!schneier Tue Mar 23 10:36:50 1993 Newsgroups: sci.crypt Path: msuinfo!uwm.edu!cs.utexas.edu!uunet!ddsw1!chinet!schneier From: schneier(a)chinet.chi.il.us (Bruce Schneier) Subject: Successful Cryptanalysis of MD5 Message-ID: <C42Gr3.M3w(a)chinet.chi.il.us> Organization: Chinet - Public Access UNIX Date: Thu, 18 Mar 1993 04:06:39 GMT Lines: 25 This is from Bart Preneel's Ph.D. thesis, "Analysis and Design of Cryptographic Hash Functions," Jan 1993, p. 191. It is about the cryptanalysis of MD5: B. den Boer noted that an approximate relation exists between any four consecutive additive constants. Moreover, together with A. Bosselaers he developed an attack that produces pseudo-collisions, more specifically they can construct two chaining variables (that only differ in the most significant bit of every word) and a single message block that yield the same hashcode. The attack takes a few minutes on a PC. This means that one of the design principles behind MD4 (and MD5), namely to design a collision resistant function is not satisfied. I have not seen the actual paper yet, which will be presented at Eurocrypt. Both PEM and PGP rely on MD5 for a secure one-way hash function. This is troublesome, to say the least. Bruce ************************************************************************** * Bruce Schneier * Counterpane Systems For a good prime, call 391581 * 2^216193 - 1 * schneier(a)chinet.chi.il.us ************************************************************************** From: burt(a)chirality.rsa.com (Burt Kaliski) Newsgroups: sci.crypt Subject: Pseudocollisions in MD5 Message-ID: <BURT.93Apr23171338(a)chirality.rsa.com> Date: 23 Apr 93 21:13:38 GMT Distribution: sci Organization: RSA Data Security, Inc. Lines: 89 NNTP-Posting-Host: chirality.rsa.com Following is a short note commenting on den Boer and Bosselaers' recent work on the MD5 message-digest algorithm. Feel free to email questions or further comments. -- Burt Kaliski RSA Laboratories ---------------------------------------------------------------------- \documentstyle[12pt]{article} \begin{document} \title{On ``Pseudocollisions'' in the MD5 Message-Digest Algorithm} \author{Burton S. Kaliski Jr. \\ {\tt burt(a)rsa.com} \and Matthew J.B. Robshaw \\ {\tt matt(a)rsa.com} \and RSA Laboratories \\ 100 Marine Parkway \\ Redwood City, CA 94065} \date{April 23, 1993} \maketitle A message-digest algorithm maps a message of arbitrary length to a ``digest'' of fixed length, and has three properties: Computing the digest is easy, finding a message with a given digest---``inversion''---is hard, and finding two messages with the same digest---``collision''---is also hard. Message-digest algorithms have many applications, including digital signatures and message authentication. RSA Data Security's MD5 message-digest algorithm, developed by Ron Rivest \cite{rfc-md5}, maps a message to a 128-bit message digest. Computing the digest of a one-megabyte message takes as little as a second. While no message-digest algorithm can yet be {\em proved} secure, MD5 is believed to be at least as good as any other that maps to a 128-bit digest. Inversion should take about $2^{128}$ operations, and collision should take about $2^{64}$ operations. No one has found a faster approach to inversion or collision. Recent work by den Boer and Bosselaers \cite{den-boer-md5} presents a special kind of ``pseudocollision'' in MD5's internal compression function, which maps a 512-bit message block $x$ and a 128-bit input state $s$ to a 128-bit output state. They show how to find a message block $x$ and two related input states $s_1$ and $s_2$ that yield the same output state: $f(x,s_1)$ = $f(x,s_2)$. Their well-thought approach exploits structural properties of the collision function to find a pseudocollision in about $2^{16}$ operations, much less than one would expect. Practical implications of this pseudocollision work to the security of MD5 are not evident. While a real collision in MD5 implies a pseudocollision (or a ``pseudo-inversion''), a pseudocollision need not imply a real collision. Indeed, a real collision, since it involves two different messages, would almost always involve {\em different} message blocks $x_1$ and $x_2$ such that $f(x_1,s_1) = f(x_2,s_2)$, but the pseudocollisions have the same message blocks. Moreover, the input states $s_1$ and $s_2$ would generally be unrelated, but the pseudocollisions' input states are the same except for four bits. There does not seem to be any way to extend den Boer and Bosselaers' approach to anything beyond the special pseudocollisions, a limitation they readily admit. It is reasonable, therefore, to believe that MD5 remains secure. While den Boer and Bosselaers have found interesting structural properties in MD5, the properties seem only to lead to special pseudocollisions and not anything approaching real collisions. Further research, of course, will give a better understanding of the strengths of MD5 and other message-digest algorithms, with the eventual hope that such algorithms can, in some sense, be proved secure. \bibliographystyle{plain} \begin{thebibliography}{1} \bibitem{den-boer-md5} Bert den~Boer and Antoon Bosselaers. \newblock Collisions for the compression function of {MD5}. \newblock In {\it Advances in Cryptology --- Eurocrypt '93}, 1993. \newblock Preprint. \bibitem{rfc-md5} R.L. Rivest. \newblock {\it {RFC} 1321: The {MD5 Message-Digest Algorithm}}. \newblock Internet Activities Board, April 1992. \end{thebibliography} \end{document}

1 0

on the road...
by George A. Gleason 17 Dec '03

17 Dec '03

...and in Berkeley the PD has a little trailer they set up all by itself, which has a radar system in it and a display in large red numerals. There is a place to hang some large printed numbers representing the speed limit. There is a large sign on the back which says, "Speed limit (printed numbers); your speed: (red display numbers), drive safely!" No tickets dispensed, but pretty effective at getting people to slow down.

1 0

Re: Anonymous vs false IDs
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> From: kovar(a)nda.com (David Kovar) > > There is a lot of effort being put into creating tools to mask identities. > I'm curious why people don't go a different route - creating a false > electronic identity? If you have control over your own system, it is easy > enough to create an account. Lacking that, there are a lot of companies > out there offering low cost accounts on Unix systems with full Internet > access. Why not get an account in a different name rather than using > anonymous remailers? If you use five different identities, why waste your money paying for five accounts, especially if some of them are used only infrequently? Why have a full UNIX account (like my account on PANIX, say) for an identity that won't need to do anything but send out a couple of email messages now and then? What if you create and kill off personas relatively frequently? Having everything centralized seems like the most logical way to go--don't forget, separate accounts would mean setting up separate .profile files, copying code from one place to another all the time, keeping duplicate copies of things, etc., etc. The exception would be when you have identities or "lives" that are truly separate, with little overlap, but even then I'd prefer having full access to all my files and robots in one place all the time. If I had an Internet connection on my own box at home, sure, it might be more convenient to segregate things in separate accounts, but most people don't have that luxury yet. --Dave.

6 5

Re: 700 Club Report on the Clipper Chip on Wednesday, October 20, 1993
by mlshew＠netcom.com 17 Dec '03

17 Dec '03

I have an error in my spelling. I spelled Jerry Berman's name wrongly as Jerry Berrman. Major apologies. And after mentioning him as just 'an eff guy' in the first message. <sigh> I'm sorry to have misspelled your name, Mr. Berman. *** Everyone, please do a search and replace of Berrman->Berman before distributing the document any further. ***

1 0

ANON: mail concerns
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hm.. there have been some concerns over anonymous mail recently... both Alan and Thomas have noted that it is easy to match up sender and destination for a remailer which processes each message as it arrives. Solution: cache all messages and process them later (once a day, once a week, etc.). For example, the remailer at elee9sf(a)menudo.uh.edu caches all incoming requests, and processes them (randomly) at midnight. I didn't even have to modify the remailer scripts to do this; rather, I wrote some extra ones. The process seems stable. The trickiest part is scheduling the remailing: I have to use the 'at' command since I can't have my own crontab. Also, Thomas mentioned what seems to be 'random remailing'. As I mentioned in a previous message ("ANON: anonymous mail"), forcing mail to progress through a network randomly also forces the final destination to be known to everybody, where before only one site knows the final destination. Also, instead of building the necessay headers to hop mail you may be able to use one of several scripts and programs available at soda.berkeley.edu Karl Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNbQEoOA7OpLWtYzAQEe0QP+KaDWOyep8+wSfEMtUjBOj8OGJMrdSCkO jAfS3zW/uASpOfZ8zgaGBhl8kFPzF9ZyEJyKV/tydIHJdQUEI9K3FU0AE4vB2Fei xcGcM16dZlSSOW/E+CkRR/3UstlRwUuHCccFACTh5SIPIG3mSSVvNMEp7Cz+SIss j5Mkq9KqJc0= =tWzv -----END PGP SIGNATURE-----

2 1

anonymous remailing/posting software
by khijol!erc 17 Dec '03

17 Dec '03

Ah, yes. Once again, it's time to upgrade the APS software here at khijol. For those who don't know, I run an anonymous posting site which posts to only a select set of newsgroups (to prevent abuse). Now that the machine is sitting on the Internet, it's time to revamp the software, and I have thought that it might be easier to hack someone else's than to redo my own (which was one of those all-day hack sessions). Double blind remailing and unique ID services are essential, with the 'nice to have' services like automatic pinging of posts, checksum verifications of posts, automatic encryption/decryption of posts, etc. would be ideal. Any ideas on where I could obtain such software? Shell scripts are OK, C is better. Perl is not desirable unless I really have to. :( Thanks! -- Ed Carp, N7EKG erc(a)apple.com 510/659-9560 an38299(a)anon.penet.fi, anon-1157(a)twwells.com If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever"

1 0

Re: All our eggs in one basket?
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Perry Metzger writes > Jim Miller says: > > However, proving them wrong while also retaining your anonymity may > > be a trick. > > If all transactions require digitally signed confirmation from the > bank, you have an audit trail from them that they can't deny was theirs. > So to prove that the bank is lying you show a third party your copy of the digitally signed receipt of the disputed transaction? I assume the third party uses the bank's public key and your public key to verify the receipt. This brings up a good question: How does the withdraw of digital money from a bank account work? In particular, how does the bank simultaneously give you money and a receipt that neither party could repudiate? I can see how they could give you the money and a receipt signed by the bank. I do not yet see how they could simultaneously give you the money and a receipt signed by both parties. I imagine the bank would use one of the simultaneous contract signing protocols and somehow produce an encryption key as the last step. The key would be used to decrypt the digital money, which was sent in an earlier step in an encrypted form. However, how can the person withdrawing the money verify the digital money is for the amount stated in the receipt if they only get the key after the last step in the receipt signing protocol. I am confused. I must not be thinking of the correct protocol. How is this situation handled? Jim_Miller(a)suite.com

2 1

Remailer cdodhner@indirect.com DOWN (temp)
by Christian D. Odhner 17 Dec '03

17 Dec '03

My sysadmin, due to some sort of security concern, has decreed that .forward files shall not be able to call any execution of code other than certain designated filters. Thus my remailer rolled over and died and lost three days of my mail. My sysadmin is helping me devise a workaround now so my remailer can be the exception to the rule, or bypass the rule entirely without compromiseing security of the site. I'll post to the list when it's back up. (btw, I'm off the cypherpunks list now, on cp-request) Happy Hunting, -Chris Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner(a)indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" My opinions are shareware. To register your copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11

2 1

Re: All our eggs in one basket?
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Perry Metzger writes > What needed is a) the bank has to be able to show a third party a > signed request for every transaction they've performed, and b) you > have to be able to show a third party a signed (by the bank) receipt > for every transaction you've performed. In other words, you are > protected because the bank can't simply claim to the arbitrator "oh, > he withdrew all his money yesterday" because they can't show an order. > The bank is protected because you can't claim "oh, I deposited ten > million dollars yesterday" if you can't show a receipt. > I'm still confused, only in a different way. Let's let I want to withdraw $10,000... 1) I send the bank a signed request to withdraw 10,000 dollars 2) The bank withdraws the money but doesn't sends it to me. I go to the arbitrator and say: "The bank cheated me!!" The bank says: "We sent you the money. Here is your withdraw request, signed by you. You are lying." ------ How can I prove that the bank did not send me the money? The withdraw protocol must somehow produce a receipt, signed by *me*, saying I receiving the money. If the bank cannot present such a receipt, then the arbitrator shouldn't believe that the bank really sent the money. Yet why would I sign a receipt before verifying that the bits the bank sent me was a valid chunk of digital money? Does this mean the bank sends me valid digital money first and I reply with a signed receipt? If so, what if I claim that the transmition failed and I didn't receive the money, but I really *did* get the money? I could then tell the bank that I changed my mind and I want them to rollback the withdraw transaction? I would walk off with a valid chuck of digital money, yet my account was not decremented. Obviously I'm still missing something. Jim_Miller(a)suite.com

2 1