4 ms·

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

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 13y ago
> 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 13y ago
  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 13y ago
  The answer is no, but I forget the exact reason why. Will do a little more research and report back.
Dylan16807 13y ago
>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.

im3w1l 13y ago

> 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 13y ago
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 13y ago
The answer is no, but I forget the exact reason why. Will do a little more research and report back.

Dylan16807 13y ago

>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.