in reply to Re: On showing the weakness in the MD5 digest function and getting bitten by scalar context
in thread On showing the weakness in the MD5 digest function and getting bitten by scalar context

No doubt. There are a LOT of namby-pamby Chicken Littles running around crying about MD5's weaknesses.

It's a HASH, for crying out loud. It's not meant to be provably perfect at identifying unique data streams.

Say you were expecting message M, with hash H. You instead get message N which also happens to hash to H.

You're worried about MD5 digests for showing falsification of data, right? Where some attacker alters the message? I contend that it will be pretty darned hard to find a useful attack on a message while maintaining MD5 integrity.

To Allied Commanders: Raiders Expected on Supply Lines in Sector 5. Keep on guard. --HQ
To Allied Commanders: No Raids Reported on Supply Lines for Sector 5, 6, or 8. Let Freedom Reign. --HQ

Until someone shows that you can (1) take any arbitrary data set M, (2) falsify it to data set N, by (3) modifying a limited portion of M in an application-useful way and (4) adding less than a gigabyte of additional data, and (5) still come out with M=>H and N=>H hash equivalence, I'll trust MD5, thanks.

--
[ e d @ h a l l e y . c c ]

  • Comment on Re^2: On showing the weakness in the MD5 digest function and getting bitten by scalar context
  • Select or Download Code

Replies are listed 'Best First'.
Re^3: On showing the weakness in the MD5 digest function and getting bitten by scalar context
by Anonymous Monk on Aug 27, 2004 at 19:10 UTC
    It's a HASH, for crying out loud. It's not meant to be provably perfect at identifying unique data streams.
    It IS meant to be computationally infeasible to find two messages with the same hash. If someone has found a way to do that, MD5 has failed at its original purpose.
    Until someone shows that you can (1) take any arbitrary data set M, (2) falsify it to data set N, by (3) modifying a limited portion of M in an application-useful way and (4) adding less than a gigabyte of additional data, and (5) still come out with M=>H and N=>H hash equivalence, I'll trust MD5, thanks.
    This is because you are ignorant. "I can't imagine an attack, therefore there is no attack."
      t IS meant to be computationally infeasible to find two messages with the same hash.

      Total bollocks!

      It is mathematically IMPOSSIBLE to reduce every 32 byte message, to a 16-byte hash and and not have duplicates. If you believe otherwise I have an infinite compression algorithm that you might like to fund development of?

      The only ignorance is that on behalf of those that don't understand simple logic--like you apparently.


      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
        You are missing the point of the attack. One of the main properties of a cryptographic hash is that is hard to FIND a collision. There are certainly collisions, but with a secure hash function and a large enough size, it is practically impossible to find another input that produces the same hash. This is very important for many cryptographic protocols.

        This attack takes finding an MD5 hash collision from difficult brute force to relatively easy. This doesn't matter too much for many uses of MD5 where security isn't important.

        Which part of "computationally infeasible" did you not understand? But I think it's better stated, "meant to be computationally infeasible to find a different message with the same hash", with two subcategories of infeasibility: where the original message is known, and where it is not.