[alinajaf]

Hi, author here, I'm glad you found it useful!

> I didnt know for example that you can basically extend an MD5ed string and keep the original MD5 value

Thank tptacek for that knowledge, I think I picked it that up in a talk he did that's somewhere on Vimeo (will link to it).

> Then again, I know that MD5 isn't a secure cryptographic hash function so I wouldn't have used it from the start. Nice to know why thats the case.

Nope! I was going to mention in this in the post but removed it to keep things simple: This particular vulnerability is not due to MD5 collisions or MD5 being cryptographically insecure. It's because of the internal mechanism (a "Merkel Damgard Construction") intrinsic to hash functions like MD5, SHA1, SHA256 and friends. Even if MD5 were cryptographically secure, this vulnerability would still present itself if used in the way I described.

Don't mean to nitpick, but with crypto small misunderstandings lead to big vulnerabilities. Hope that makes sense :)

[im3w1l]

> It's because of the internal mechanism (a "Merkel Damgard Construction") intrinsic to hash functions like MD5, SHA1, SHA256 and friends. Even if MD5 were cryptographically secure, this vulnerability would still present itself if used in the way I described.

Thanks for pointing that out, didn't know that.

Just for fun, if they had written message+secret instead of secret+message it would have been ok (although bad practice)?

calculated_mac = OpenSSL::Digest::MD5.hexdigest(message+secret)

[tptacek]

Secret suffix MACs are insecure if your hash function isn't collision-resistent. To illustrate: MD5 isn't collision-resistent, but HMAC-MD5 has no currently known viable attacks, because it isn't simple a secret-suffix MAC.

So it's true that using a secret-suffix MAC is safer than using a secret-prefix MAC, but if you know enough to make that choice, you know enough to use HMAC.

[alinajaf]

The answer is no, but I forget the exact reason why. Will do a little more research and report back.

[Dylan16807]

>This particular vulnerability is not due to MD5 collisions or MD5 being cryptographically insecure. It's because of the internal mechanism (a "Merkel Damgard Construction") intrinsic to hash functions like MD5, SHA1, SHA256 and friends.

That's what I like about SHA3. It only dumps part of its internal state so there is no possible way to resume from a hash. This also makes it viable as a PRNG or cipher stream.