Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The long tail of MD5

tedunangst.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: The long tail of MD5

#11

Post by TillE »

JoachimS wrote: post #7
yuhong wrote: post #4

Earlier quoted context omitted.

I know, but this does not make MD5 as broken as ROT13.

Depends on what you place in the expression broken. Md5 is useless in anything remotely related to security. An as a non secure function it is slow.

> Md5 is useless in anything remotely related to security

There are serious flaws with MD5, and I would never recommend its use today. But there is no known attack that can generate a malicious binary with an arbitrary hash. The attacker needs to control both files to generate collisions, which is a huge limitation.

Maybe those attacks will exist some day. But I wouldn't be setting fire to all your legacy software without first understanding exactly how they use MD5, and if that is vulnerable to any known attack.

Re: The long tail of MD5

#13

Post by lisper »

pbsd wrote: post #10
JoachimS wrote: post #6

Good article that really shows why design decisions can have impact 20, 30 years or more. This is why I get fairly upset when people design something new I n 2014 that uses md5. Yes even if your application does not use md5 for anything security related, the mere fact that you use a bad, slow algorithm should be considered wrong. And adding new dependencies will make it harder for us to migrate away and extend that t…

Do NOT use SipHash as a cryptographic hash function. It is designed to be a PRF, and its output length is way too small to make it collision-resistant when used as a hash. SHA-3, SHA-512/256 or BLAKE(2) (in increasing order of performance) are suitable cryptographic hash functions.

I think you meant: it [SipHash] is NOT designed to be a PRF.

Re: The long tail of MD5

#14

Post by yuhong »

TillE wrote: post #11
JoachimS wrote: post #7

Earlier quoted context omitted.

Depends on what you place in the expression broken. Md5 is useless in anything remotely related to security. An as a non secure function it is slow.

> Md5 is useless in anything remotely related to security There are serious flaws with MD5, and I would never recommend its use today. But there is no known attack that can generate a malicious binary with an arbitrary hash. The attacker needs to control both files to generate collisions, which is a huge limitation. Maybe those attacks will exist some day. But I wouldn't be setting fire to all your legacy software wi…

I think with practical chosen prefix attacks this may have changed.

Re: The long tail of MD5

#15

Post by bodyfour »

yuhong wrote: post #5

Content-MD5 has been removed from HTTPbis. Don't forget VBA digital signatures BTW, for which MD5 is the only choice. I wonder how feasible a collision attack would be.

Yeah a couple years ago I was trying to determine whether to support Content-MD5 in some HTTP software I was writing I could find nobody actually using it. There was an attempt a decade ago to make Firefox validate with it, but that died: https://bugzilla.mozilla.org/show_bug.cgi?id=232030

Also the author is wrong that there isn't a proposed replacement -- it's the "Digest:" header (RFC 3230) although I don't think anybody uses that either.

Re: The long tail of MD5

#16

Post by jonstewart »

MD5 also remains quite popular for file hashing/hash set analysis. I.e., is this file a member of a known set? For example, NIST's NSRL still includes MD5 hashes.

* This is not an endorsement of MD5 for such use cases.

Re: The long tail of MD5

#17

Post by Andys »

JoachimS wrote: post #6

Good article that really shows why design decisions can have impact 20, 30 years or more. This is why I get fairly upset when people design something new I n 2014 that uses md5. Yes even if your application does not use md5 for anything security related, the mere fact that you use a bad, slow algorithm should be considered wrong. And adding new dependencies will make it harder for us to migrate away and extend that t…

Slow? I thought md5 was faster than the SHA-* family

Re: The long tail of MD5

#18

Post by NoMoreNicksLeft »

yuhong wrote: post #4
jmartinpetersen wrote: post #3

Earlier quoted context omitted.

Collision attacks are trivial. It's been almost ten years since Ron Rivest declared MD5 broken.

I know, but this does not make MD5 as broken as ROT13.

Rot13 is actually useful. I have perl scripts which download my bank statements, running from cron. Gets the latest every month. These perl scripts use passwords, but without knowing that they are there, who would find them?

The trouble is, they have to pass the name of the form field to the server on the other side, which is some variation of "password". So anyone doing a simple string search will eventually find the perl scripts, and have access to my passwords (supposing they have root).

If I rot13 the form field name, and then have the name be rot13('cnffjbeq') in the script, this makes is unsearchable.

Re: The long tail of MD5

#19

Post by pbsd »

lisper wrote: post #13
pbsd wrote: post #10

Earlier quoted context omitted.

Do NOT use SipHash as a cryptographic hash function. It is designed to be a PRF, and its output length is way too small to make it collision-resistant when used as a hash. SHA-3, SHA-512/256 or BLAKE(2) (in increasing order of performance) are suitable cryptographic hash functions.

I think you meant: it [SipHash] is NOT designed to be a PRF.

No, I meant what I wrote. SipHash is fine as a keyed primitive -- 128-bit security against key recovery, (64 - t)-bit security against 2^t forgery attempts.

However, as a hash function (e.g., with a fixed key), it is entirely too weak: 2^32 work for a collision, and 2^64 work for arbitrary (second-)preimages.

Re: The long tail of MD5

#20

Post by kemayo »

NoMoreNicksLeft wrote: post #18
yuhong wrote: post #4

Earlier quoted context omitted.

I know, but this does not make MD5 as broken as ROT13.

Rot13 is actually useful. I have perl scripts which download my bank statements, running from cron. Gets the latest every month. These perl scripts use passwords, but without knowing that they are there, who would find them? The trouble is, they have to pass the name of the form field to the server on the other side, which is some variation of "password". So anyone doing a simple string search will eventually find th…

Note to self: add "cnffjbeq" to my password-finder scripts.
Post reply on HN