Fwd: The PoinFULLness of the MD5 'attacks'

[james hughes]

For this discussion, I think we are missing the point here...

1. With a rogue binary distribution with correct hash, this is -at 
least- a denial of service where the customer will install the rogue 
binary and it will crash in the area that the information was changed. 
MD5 based Tripwire will not catch this happening if this is done on the 
distribution machine.

2. If the rogue binary is a driver that gets into the kernel, it could 
cause a crash and that crash -could- cause a kernel exploit.

3. A modification to an seldom used section of code that can be invoked 
in some non-typical way can cause a machine to crash on command.

4. Offline, the attacker could automate a trial and error scheme to 
create random collisions and testing each until one produces an effect 
to their advantage and then substitute it for the real one.

Again, anything that gives the legitimate user a feeling of security 
(because the hashes match) and allows the attacker to do anything to 
their advantage is a failure of the MD5 algorithm.

Maybe these are low probabilities... Are you willing to step up and say 
there is nothing that the attacker can ever do using these collisions? 
I'm not.


My suggestion is that all distributions publish the MD5 and SHA-256 
hashes for a while and then drop the MD5 based ones in a year or so.


thanks

jim




On Dec 15, 2004, at 10:45 AM, Tim Dierks wrote:

> On Wed, 15 Dec 2004 08:51:29 +0000, Ben Laurie <ben at algroup.co.uk> 
> wrote:
>> People seem to be having a hard time grasping what I'm trying to say, 
>> so
>> perhaps I should phrase it as a challenge: find me a scenario where 
>> you
>> can use an MD5 collision to mount an attack in which I could not mount
>> an equally effective attack without using an MD5 collision.
>
> Here's an example, although I think it's a stupid one, and agree with
> you that the MD5 attack, as it's currently known to work, isn't a
> material problem (although it's a clear signal that one shouldn't use
> MD5):
>
> I send you a binary (say, a library for doing AES encryption) which
> you test exhaustively using black-box testing. The library is known
> not to link against any external APIs (in fact, perhaps it's
> implemented in a language and runtime with a decent security sandbox
> model, e.g., Java). You then incorporate it into your application and
> sign the whole thing with MD5+RSA to vouch for its accuracy.
>
> I incorporate several copies of a suitable MD5 collision block in my
> library, so one of them will be at the correct 64-byte block boundary.
> I can then modify bits inside of my library, which car checked by the
> library code and cause it to change the functionality of the library,
> yet the signature will still verify.
>
> This would be pretty easy to do as a proof-of-concept, but I don't
> have the time.
>
> - Tim
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com