Ok, you win. "Cryptographic hash" is not the formally correct terminology. I hang my head in shame. What I find interesting is that you dig up a quotation that says exactly what I've been telling you, but with different words, and use it to claim that I'm wrong.

I wasn't quoting the RFC. It's interesting that they used almost the same language I did.

You seem to think that your quotation says MD5 is a digital signature. It does not. It's telling you that MD5 can be used as part of a digital signature protocol.

You also seem to think that the RFC is giving you a comprehensive list of all the allowable uses of MD5. It's not. It says "MD5 is part of this complete breakfast," but you don't have to eat it that way. If you want to learn what you should eat for breakfast, you have to study nutrition, not breakfast cereal advertisements.

Comment on
Re^9: On showing the weakness in the MD5 digest function and getting bitten by scalar context
Replies are listed 'Best First'.

The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.

MD5 does the compression. RSA does the encryption. Taken together, this operation is called a digital signature. RFC1321 does not lay this out for you in full detail, because it is not meant to be "the source" of information about anything except how to implement the MD5 algorithm.

I'm not sure, at this point, what your beef is. MD5 was designed to have a certain set of properties. People used it, assuming that it did in fact have those properties. That assumption was shown to be false. Yet you seem (in a number of threads on perlmonks) to be arguing that people should continue to use MD5 anyway.

Funnily enough, I don't have a beef. Nor have I advocated anyone should continue to use md5--nor that they should stop.

My original assessment of the significance of the "discovery" was that is was overstated. Since then, I have attempted to assess it's impact (for myself) by applying the information available about the discovery, to the various applications to which md5 is used.

I've tried to counter the FUD that anything that uses md5 is an immediate security risk leaving it's users immediately vulnerable. And counter the enevitable reactions from many users that they must immediately and irrevocably seek some alternative technology to secure their systems, websites and other applications.

I've tried to point out that it was always known that the multiple messages are possible for any given md5. And that for most applications, incorporationg the knowledge of that possibility, into the design of the application using md5, can entirely eliminate any consequences of that possibility becoming a reality.

I've tried to demonstrate that even those applications that chose to ignore the possibilty of "duplicates" in their design, the nature of the mechanism by which (so far) a duplicate has been generated, means that the content of the mathematically generated message is just an arbitrary collection of bytes.

The attacker using the message does not control that content. As such, any attempt to use such a generated message to attack an md5 based system is:

unlikely to go unnoticed.

unlikely to benefit the attacker in any meaningful way.

even in those applications (so far, one example described) in which the possibility of duplicates could have the effect of disrupting the application, that even simplistic steps can be taken to re-secure that application with only minor changes to the design of the application. And without requiring any "new technology" to do so.

Basically, I've attempted to apply a little calm logic to the situation and understand the actual implications of this discovery for myself, and those purposes to which I put md5. On the way, I've also tried to consider the exposure that the discovery leads to for many common applications of md5 as they have come up.

That's it. Drawing my own conclusions, for my own existing uses of md5, and attempting to contribute to a discussion about the likely impact of the discovery for other, more important, existing uses of md5.

Just as double-DES means that the known mathematical attack against a single DES system must be applied to 2 DES keys simulataneously and repeated until a compromise that matches both is found. And the multiplication factor of the work that must be done by the attacker means that even if that mathematical attack can be successfully applied to two keys simultaneously (which is still extremely unlikely, though not proven impossible), it will take a very, very, long time. Using triple-DES makes the attack not just extremely unlikely to succeed, but so laborious as to be a total waste of time trying.

Equally, using two nested md5's means that for an attack to be effective, not only must the attacker apply the mathematics to both keys to find duplicate messages. They must do it such that the math produces a single message that (in whole or part), matches both keys. In my less than authoratative opinion, that is as close to impossible as I will ever need to consider.

It is my conclusion (drawn for my own purposes), that if the algorithms using md5 accepted the reality that somewhere, sometime, a duplicate will come up, and incorporate that reality into their design, then the affect of that reality can be completely negated. And any application, especially a security application that ignores the congectural nature of the uniqueness factor of md5s, and relies upon that uniqueness, is broken--not by this discovery, but by design.

Others must reach their own conclusions, based on their knowledge of their uses of md5, and the urgency of maintaining their security.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon