10

I was recently reading that MD5 is "broken" because it's pretty easy to generate collisions (like 2^(L/2)). And the SHA1 (theoretically) fares no better. The solution seems to be hash algorithms that are very slow in comparison.

I am wondering why can't people combine these fast algorithms to get the best of both security and speed? What would be the time complexity to generate a simultaneous MD5 and SHA1 collision? And if it's hard enough, would these make a viable candidate for collision resistant hash applications?

(By simultaneous collision I mean generating a string with same MD5 and SHA1)

xyz
  • 465
  • 1
  • 5
  • 9

1 Answers1

21

Surprisingly enough, it would appear that generating a simultaneous collision wouldn't be that much more expensive than generating a single collision for SHA-1.

The basic idea is to form a $2^{64}$ wide multicollision on SHA-1; that is, $2^{64}$ distinct messages that all SHA-1 hash to the same value. We can do this by using Joux's idea of forming finding 64 different colliding blocks $B_{i, 0}, B_{i, i}$ such that all sequences $B_{0, a}, B_{1, b}, B_{2, c}, ..., B_{63, z}$ all share the same SHA-1 hash; this can be done by finding 64 successive SHA-1 collisions. The best estimate on finding a single SHA-1 collision is $2^{61}$ SHA-1 compression function calls (Stevens); hence the effort to find 64 such collisions is $2^{67}$ compression function calls.

Once we have such a $2^{64}$ wide multicollision, we just do an MD5 hash of each, and look for an MD5 collision; this takes $2^{65}$ MD5 compression function calls, and yields a collision with good probability.

This yields a simultaneous SHA-1 and MD5 collision with an expected $2^{67}$ computational effort.

poncho
  • 154,064
  • 12
  • 239
  • 382