December 2003 - cypherpunks-legacy

RE: MD5 weakness ? [was Re: Netscape Log
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Steve Bryan[SMTP:sbryan@maroon.tc.umn.edu] Sent: Tuesday, October 24, 1995 3:08 PM To: Dr. Frederick B. Cohen Cc: cypherpunks Subject: Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF] Dr. Frederick B. Cohen writes: >In the case of the trust being placed in MD5 by Netscape, the assumption >being made (without adequate support as far as I can tell) is that an >MD5 checksum cannot be forced, through a chosen plaintext attack, to >yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to >allow the known plaintext attack that gets the RSA private key used to >authenticate messages. As far as I am aware (and I may not be aware of >everything) there is no reference work to support this assumption. If >the assumption is wrong, then the whole SSL can fall to a selected >plaintext attack launchable (presumably) through those general purpose >Java aplets we have heard so much about. With a mailing list this large and diverse one can reasonably assume a range of interests and expertise. What I don't understand is your agnostic stance on something as apparently basic as MD5. If computer security is your purported area of expertise why have you not reached any firm conclusions about it? I understand that rigid conclusions are unsafe (eg they'll never prove Fermat's last theorem) but it is not like every question is equally open. Do you have a realistic attack on MD5 or is this sophomoric claptrap? How do you propose to generate messages with specific message digests? Assuming you could somehow, how do you proceed to use that information to your advantage? So let's say I have a message digest and I'm retrieving the allegedly corresponding message which you have the opportunity to alter to your heart's content. How would you proceed, even in principle, to defeat MD5? I realize I might be assuming too much when I posit that I have the true MD5 for the message but my understanding is that you feel that MD5 might be vulnerable. I've given you all the known plaintexts. Is there a next step? +---------------------------------------------------------------------- |Steve Bryan Internet: sbryan(a)gofast.net |Sexton Software CompuServe: 76545,527 |Minneapolis, MN Fax: (612) 929-1799 |PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D E1 8C A6 9B A9 BE 96 CB +----------------------------------------------------------------------

1 0

RE: MD5 weakness ? [was Re: Netscape Log
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Dr. Frederick B. Cohen[SMTP:fc@all.net] Sent: Tuesday, October 24, 1995 4:01 PM To: cypherpunks Subject: Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF] ... > I believe Dr. Cohen's point is that no-one knows, AFAIK, how to prove that a > one-way hash is truly one-way (uninvertible). We cannot prove that MD5 is > secure, ergo we cannot (completely) trust it. [Please correct if this is a > substantially incorrect inference.] > > One of the standard responses is "it's the best we can do". When people said > this about PGP, FBC made some (IMHO) interesting comments about the > encryption he uses in various circumstances. Perhaps he would like to share > his personal choices of one-way hash functions with us. Since you asked: It's a really complex issue. As a fundamental, we know that any "one-way" hash function must be many-to-one, which means that, in practice, there are always large numbers (2^large numbers) of sources for any given hash. This means that forgeries are always possible. I know of no way to prove that (and no convincing argument that the workload for creating) a forgery is hard for any "one-way" hash function. This seems to mean that we are always betting on faith about these things. The techniques that seem to be reasonably good are; modular exponentiation in a modulus that's the product of two appropriate primes (a.k.a. RSA but throw out the private key when you create it); certain classes of non-linear feedback shift registers of high degree; and some general class of mixing algorithms like MD5. The RSA-type hash is slow, and some great mathematician may show up tomorrow and lay waste to the whole thing. Non-linear feedback shift registers have the advantage that we don't know how to factor high-degree equations, so we don't know how to make simple closed form solutions to find output values. MD5-type systems are good because they combine diffusion and confusion and avoid a lot of the more well-known flaws as far as we know. None of these reasons are particularly convincing, so I think we have to take a risk management approach. So the ultimate question here is, how much are we willing to bet that nobody can break one of these in the intended application over a particular time frame. I trust the RSA and NLFSR systems, if reasonably well implemented, for a single short time-frame low-valued transaction. For example, pick a good pseudo-random number and create an RSA one-way hash of 512 bits (the random number issue is of course another whole area), encrypt the first bloack, Xor with the second block, encrypt the result, etc. till done, then Xor again with the original random seed, send the file and the hash along with the one-way key, and get a confirmation back within a few days. I don't trust any of them as a basis for running a major part of an economy over open communications links, and I especially don't trust them when combined or when the security of one depends on another. To run an economy, I think you need more redundancy, more personnel security, more stop-loss capabilities, physically secure devices, independent checks and balances, etc. Someone on this list mentioned that the banking system trusts the RSA and MD5, etc. but this seems to me to be a mischaracterization. They trust these systems to an extent, but they have key change requirements, regular audits, physical security, relatively secured communications lines (when compared to the Internet), strong procedural controls (most of the time), and other such protections, and they still get hammered for a few million now and then. This is probably enough for now, since the list is probably getting tired of my posts and I have made the major points. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

RE: (fwd) Chaum vs. Stein
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Robert Hettinga[SMTP:rah@shipwright.com] Sent: Tuesday, October 24, 1995 3:52 PM To: cypherpunks Subject: (fwd) Chaum vs. Stein --- begin forwarded text To: www-buyinfo <www-buyinfo.allegra..att..com(a)mail.checkfree.com> From: Andrew Barrett/CheckFree Corporation <Andrew_Barrett(a)checkfree.com> Date: 24 Oct 95 13:38:40 EDT Subject: Chaum vs. Stein Wanted to save my 'me too' until a time I could piggy-back it onto something a little more pithy (and I DO mean 'little'). Robert, thanks for taking the time and energy for filtering cpx and forwarding the best. David, thanks for providing the forum. Now that _that's_ out of the way ... I've just been handed a registration booklet for The Bank Administration Institute's Retail Delivery '95 conference December 2-6 in Atlanta. Notable speakers include The Bill, MasterCard CEO Eugene Lockhart, Visa International CEO Edmund Jensen, Intuit CEO Scott Cook and Checkfree CEO Pete Kight (among others). Featured on page 6 is a "Fireside Chat: The Financial Marketplace of the Future" moderated by Lou Dobbs... How warm and fuzzy. What really caught my eye was a panel discussion on Internet Security scheduled for that Wednesday. The panelists are David Chaum, Cybercash CEO William Melton, and FV CEO Lee Stein. If anyone goes, tell us all how it went! Kicker - the postal frank is of the "non-profit organization" variety. BIA's site is at http://www.bai.org --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

RE: Sun speaks out - but not to the cyph
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Todd Glassey[SMTP:todd@lgt.com] Sent: Tuesday, October 24, 1995 12:52 PM To: David A Wagner Cc: cypherpunks Subject: Re: Sun speaks out - but not to the cypherpunks >-----BEGIN PGP SIGNED MESSAGE----- > >In article <v02110101acaf51651ef9(a)[204.156.156.4]>, >Todd Glassey <todd(a)lgt.com> wrote: >[ lines marked > > are from fc(a)all.net (Dr. Frederick B. Cohen) ] >> Pardon the flame but I really have just about heard enough of this BS... >[...] >> >> The area where we can (must) build trust is the computing base. >> >> Traditionally, this has been the OS, but in the case of java, it is >> >> the java interpreter (such as netscape 2.0 and hotjava). The browser >> >> is now the TCB (trusted computer base) for all practical purposes... >> > >> >Read: The Java interpreter is supposed to be a TCB. >[...] >> >Who here truly believes that the implementations of Java meet the >> >requirements of a TCB? >[...] >> Dr. Fred, you seem to spend a lot of engery slamming Java and HotJava. >[ ... flame deleted ... ] > > >No, here I think Dr. Cohen's comments are right on the mark. > >The Java interpreter *is* supposed to be a trusted computing base. >Do we have any reason to believe that this trust is well-placed? > >(If you don't agree, go through the Orange Book evaluation criteria, >and pay special attention to the assurance sections...) >- --- >[This message has been signed by an auto-signing service. A valid signature >means only that it has been received at the address corresponding to the >signature and forwarded.] > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.2 >Comment: Gratis auto-signing service > >iQBFAwUBMIwG2CoZzwIn1bdtAQEpowGAgHiyk0tTQk5SO/3TR5EZRMFmUy/TjQmu >NbYIt0R/Tf0g9xWbolm5XN0alu947uJs >=UZH0 >-----END PGP SIGNATURE----- Sorry abopt the above flame-war I caused. My point was almost benign in and of itself. Yes, the Java concept is sound, No, the currently available implementation has some real architectural considerations that must be addressed in order that we can build a stable and secure platform atop it. My real issue is that there is so much time spent on this list knocking the individual spokes that make up this wheel we call Electronic Commerce, that it is more and more costly to filter out the technology from the background noise. Still because of the value of that technology, I and others are forced to spend precious hours reviewing all that comes across our desks. Bluntly being an active member of several Security and Payment Mechanism working groups I view some 150+ pieces of email a day and sometimes get frustrated by the amount of noise, or the roar in the background, about what are to the largest percentage of us, meaningless dribble... Still there is the occaisional golden nugget that makes it all worth while.. Again My apologies to have stirred up this mess. I will retreat under my desktop from the mele' that seems to be unending. Todd Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd(a)lgt.com (415) 324-4318 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----

1 0

RE: Verification of Registration
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Scott Brickner[SMTP:sjb@universe.digex.net] Sent: Tuesday, October 24, 1995 2:09 PM To: x85849i1 Cc: cypherpunks Subject: Re: Verification of Registration "Raymond Val" writes: >Lynne L. Harrison writes: > >> Curious. Did anyone else receive this unsolicitated *invitation*? > >Everybody who receives mail from cypherpunks(a)toad.com received this >message becuase the message was addressed to >cypherpunks(a)toad.com. Apparently someone may have >joined this 'group' or service and used the cypherpunks address as >the e-mail address. Mayhap the cypherpunks(a)toad.com / cypherpunks >userid/password. > >This would be my guess, of course. Mine too. > >Does anybody know what this service does? C|NET Central is a cable TV show which reports on the 'net. The service is their on-line address where you can get more details on stuff they report. Doesn't seem to be especially c-punks related, but I guess someone didn't like the idea of having to reveal his identity just to look at a web page. You can probably assume that the password for the "cypherpunks" userid on the server is either "cypherpunks" or "writecode".

1 0

RE: Hash collisions [was Re: MD5 weaknes
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Matt Blaze[SMTP:mab@crypto.com] Sent: Tuesday, October 24, 1995 3:02 PM To: hallam Cc: cypherpunks Subject: Hash collisions [was Re: MD5 weakness ? ...] > >>As to weaknesses, I seem to remember that someone managed to forge a >>modification to a program used to observe networks on a Sun so that it >>had the same MD5 checksum as the official trusted version. But whether >>this is real is not strictly the issue. > >Ron has not mentioned such an event to me and if that were the case I would >seriously doubt that he would not have been told about it. The only comment he >generally makes is that he wrote MD5 because "MD4 was making me nervous". > >>In the case of the trust being placed in MD5 by Netscape, the assumption >>being made (without adequate support as far as I can tell) is that an >>MD5 checksum cannot be forced, through a chosen plaintext attack, to > >Netscape do not simply use the MD5 of the message, they are using (as I >understand it) the PKCS#1 standard for makoing the signature. If not they >probably have severe problems. > >>There has been no limit given by anyone on this list to the level of >>trust they place in MD5. Several people have posted (without >>contention) that MD5 is sufficiently trustworthy to trust billions of >>dollars in commerce to it's being able to prevent a selected plaintext >>attack as eluded to above. > >NIST and the NSA trusted MD4 sufficiently to base SHA upon it. SHA is preferab le >in many ways to MD5, it has a different approach to extending the scheduling a nd >resist differential cryptanalysis. There is a problem with the compressor >function of MD5 which I dislike. This is fairly irrelevant though since SSL >allows other digests to be used. > > Phill I hesitate to jump in to this exchange given the defensive and vague nature of the discussion, but... While I agree that SHA seems preferable, for a number of reasons, to MD5, it is worth noting that Hans Dobbertin of the German Information Security Agency recently found a collision in MD4. His attack allows you to generate a pair of plainexts that generate the same hash. A fast technique for finding a second plaintext that hashes to some given value remains an open problem with MD4 (and SHA and MD5, for that matter). As far as I can tell the attack does not readily generalize to MD5 or SHA. -matt

2 1

RE: MD5 weakness ? [was Re: Netscape Log
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Laurent Demailly[SMTP:dl@hplyot.obspm.fr] Sent: Tuesday, October 24, 1995 6:45 PM To: Dr. Frederick B. Cohen Cc: cypherpunks Subject: Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF] <grrrrrrr> Frederick B. Cohen writes: > > > [...] uses an MD5 checksum which the members > > > of this list seem to place unlimited trust in (incorrectly in my view, > > > but that would be picking two nits with one keyboard entry). [me]> Can you elaborate WITH FACTS on the supposed weakness of MD5 ? ********** I wonder what is your definition of facts... > I didn't say that there were any weaknesses in MD5, all I said was: > "unlimited trust ... (incorrectly in my view...)" > > The lack of adequate demonstration of strength is not the same as a > weakness. It represents only a lack of adequate assurance for placing > more than a certain amount of trust in MD5 for the purpose it is being > used to accomplish. > > As to weaknesses, I seem to remember that someone managed to forge a > modification to a program used to observe networks on a Sun so that it > had the same MD5 checksum as the official trusted version. But whether This is absolute bullshit with a probability of (2^128-1)/2^128 > this is real is not strictly the issue. On the contrary real things should be the issue... not random thoughts > In the case of the trust being placed in MD5 by Netscape, the assumption > being made (without adequate support as far as I can tell) is that an because you can't tell 1+1=2 doesn't imply people have to worry... > MD5 checksum cannot be forced, through a chosen plaintext attack, to > yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to > allow the known plaintext attack that gets the RSA private key used to > authenticate messages. As far as I am aware (and I may not be aware of > everything) there is no reference work to support this assumption. If The fact that you obviously didn't take the time to do any search/reading on the subject does not allow you to go on with mad assumptions... > the assumption is wrong, then the whole SSL can fall to a selected > plaintext attack launchable (presumably) through those general purpose > Java aplets we have heard so much about. FYI, ( false => false ) is a true expression... starting from false assumption you can demonstrate *anything* { if 1+1!=2, lots of things "fall"} [me]> [btw who talked about 'unlimited' trust ?] > There has been no limit given by anyone on this list to the level of > trust they place in MD5. Several people have posted (without > contention) that MD5 is sufficiently trustworthy to trust billions of > dollars in commerce to it's being able to prevent a selected plaintext > attack as eluded to above. If you think we should trust it, and you > don't limit your assessment of trust, what other assumption should I > make? If several people proclaim that trust and nobody stands up in > disagreement, tacit agreement is my normal (although not necessarily > justified) assumption. AGAIN, the limit is 2^128 computer operations (as I quoted from the rfc days ago), which is imo certainly NOT the weakest part of the security chain... Do you actually read anything people are mailing or writing ? </grrrrrrr> sorry again, I feel tested... dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept cracking SEAL Team 6 counter-intelligence DES Pasqua Qaddafi class struggle

1 0

RE: Hack DigiCash: Payee Anonymity
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Hal[SMTP:hfinney@shell.portal.com] Sent: Tuesday, October 24, 1995 12:44 PM To: cypherpunks Subject: Re: Hack DigiCash: Payee Anonymity nobody(a)replay.com (Name Withheld by Request) writes: >Now all we need is to do is get some specs on how DigiCash's software works >so that we can code this. I expect that this method will become quite >popular. To withdraw DigiCash, one must come up with $250 to start, sign a >bunch of forms, etc. I suspect that most people would rather change money >in lesser amounts, probably under $50. This opens up a huge market for >Blacknet money exchangers. I would gladly pay Tim's Internet Cash Exchange >a commission to exchange $50 worth of greenbacks for Digicash instead of >dealing with Mark Twain and shelling out $250 to start.. I don't believe this $250 is correct. The only place I see such a number is on the application form, in the following clause: "A maintenance fee of the foreign equivalent of $10 will be imposed each statement period if the balance in your account falls below the foreign equivalent of $250 on any day of the period." This is for a "WorldCurrency Access Interest Account", which I don't think is what is used for ecash. For ecash the account opening fee is $11 and the per-month fee is $5. I don't see any reference to required account minimums. As far as the issue of coding up a payee-blinding cash system compatible with this ecash, I agree that it would be good to see some specs now that ecash is for real. IMO Chaum has been getting a free ride based on his reputation, with many people assuming that anything he is associated with must be done right. It is time for him to open his hand and reveal his protocols so that people know exactly what they are trusting their money to. Hal

1 0

RE: Does your software?
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Peter Wayner[SMTP:pcw@access.digex.net] Sent: Tuesday, October 24, 1995 2:33 PM To: Dr. Frederick B. Cohen Cc: cypherpunks Subject: Re: Does your software? >My get-only server is available in source form, is 80 lines long and >thus easily understood, has been shown to meet security properties, is >now in the process of being mathematically proven to meet those >properties, and is published in a refereed journal which can be used to >confirm its contents in detail. Hence, I do provide secure distribution >through purely physical means. > Uh, proofs only go so far. There was one Cornell CS professor who was a real devotee of "proving" your programs correct. He even published one of his proofs in a "refereed" journal. Big whoop. It still had an error. Proofs can help identify flaws, but they can never rule out all flaws. That's why their name is so bogus. I wouldn't be surprised if you could prove that the Finger daemon, which is sort of like a really low-level GET-ONLY HTTP server, is also safe. In fact, your math proving ability could probably even prove the pre-Robert Morris finger daemon is safe and secure. If programmers don't think of preventing finger requests longer that 512 bytes then why should the head-in-the-clouds program provers? - Peter >-- >-> See: Info-Sec Heaven at URL http://all.net >Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236 P.S. "FC" is your log in and "FC is found inscribed in the writings of the Unabomber. Coincidence? on't speak officially, were to be torn apart and the ulterior motives speculated upon, I'd either shut up on this list or get off it completely. (Recall that we had Marc Andreessen on this list last December--for whatever reasons, and there are likely several, he left. I recall many attacks on his company. He perhaps figured "What the hell do I need this for?") Legitimate, scientific analysis is commendable. The brute force attack on Netscape was great, and even better was the random seed attack. But many of the attacks are less solid: "How can you people at Digital Datawhack produce such crap? The assumptions you make in the Flogisticon module are disgusting, another example of security through obscenity." (What I think this piling on is likely to accomplish is to push company list subscribers here to just shut up. They see that the more is said by folks from Netscape, as the best current example, the more fireworks and insults ensue. The less that is said the better. This is not a good situation.) I'm not arguing for "niceness," just that some of the edge be taken off the attacks. The "bounties" that are being offered in press releases have the danger of inviting premature announcement of results. And of discouraging companies from actively participating in this list and discussing what might be done to improve security. Just my views. No doubt some will think I'm a shill for some company. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

RE: Don't Kill the Messenger--A New Slan
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Scott Brickner[SMTP:sjb@universe.digex.net] Sent: Tuesday, October 24, 1995 12:59 PM To: Adam Shostack Cc: Cypherpunks Mailing List Subject: Re: Don't Kill the Messenger--A New Slant on Remailers Adam Shostack writes: > Who cares if you can read messages encrypted to the key or >not? Let everyone connect and download whatever messages they want to >see. They're encrypted, after all. Two reasons. One, it cuts down on traffic. Why bother to waste the server's bandwidth on something the client can't read anyway. The only possible reason someone could be asking for the data is because they're trying to compromise the key or do traffic analysis. Why help bad guys? Second, there's no reason the messages need to be encrypted. The server can accept messages addressed to *any* string of eight hex digits, and doesn't care about the content. The server needn't limit the kinds of encryption used in the actual message. It only cares that the recipient is "really" (in some sense) the right reciever. The original mental prompt for the idea came from the discussion of the "key-is-the-person" model. I was trying to devise a scenario where it was possible to know of an entity only through his key, and came up with this. I also included the idea that messages signed by the key would be forwarded by the server after being pseudonymized to the keyid. That way, the user could participate in mailing lists purely identified by the key.

1 0