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

21–30 of 58 posts

Re: The long tail of MD5

#21

Post by v64 »

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.

I believe the spirit of the original poster's message was that SipHash is not strong enough to be used for cryptographic purposes.

Re: The long tail of MD5

#22

Post by lisper »

pbsd wrote: post #19
lisper wrote: post #13

Earlier quoted context omitted.

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.

OK... so if it's suitable as a PRF, then you should be able to widen the output by using two different keys and concatenating the results, no?

Re: The long tail of MD5

#23

Post by tptacek »

v64 wrote: post #21
lisper wrote: post #13

Earlier quoted context omitted.

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

I believe the spirit of the original poster's message was that SipHash is not strong enough to be used for cryptographic purposes.

No, SipHash is acceptable cryptographic PRF; it's just not acceptable as a standalone general-purpose cryptographic hash.

A PRF is secure as long as attackers don't get to know exactly how it works, which, with SipHash, they don't if they don't know the key used for it.

A cryptographic hash function is secure --- it's Hard to find two inputs that produce the same output, it's (even) Hard(er) to find a specific input that generates a given output --- even when it's not keyed.

SipHash is a cryptographic building block that is performant in part because it takes advantage of relaxing the constraint of being a good cryptographic hash function, and only tries to be a good cryptographic PRF.

Re: The long tail of MD5

#25

Post by WhitneyLand »

Andys wrote: post #17
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

Yes, way faster. It would be great if it weren't for those pesky collisions.

Re: The long tail of MD5

#26

Post by VLM »

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.

As a non secure function its "killer app" is being everywhere on every platform and being massive overkill for many applications.

Re: The long tail of MD5

#27

Post by smackfu »

jonstewart wrote: post #16

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.

Do the security problems with MD5 make it bad as a hashing algorithm?

Re: The long tail of MD5

#28

Post by tkmcc »

smackfu wrote: post #27
jonstewart wrote: post #16

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.

Do the security problems with MD5 make it bad as a hashing algorithm?

Not necessarily, but if that's your use case (and the hashing speed isn't extremely critical), why not use a better algorithm with a larger output?

Re: The long tail of MD5

#29

Post by derobert »

smackfu wrote: post #27
jonstewart wrote: post #16

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.

Do the security problems with MD5 make it bad as a hashing algorithm?

Depends. Can an attacker introduce files? If so, he can probably introduce collisions. In most uses of a hash, that's an issue—a performance (DoS) issue if nothing else.

If the application was just looking for a longer CRC/Adler32/etc. and not depending on the hash to be strong against attack, then MD5 wasn't an appropriate choice in the first place, as its much slower than need be. But the security problems are irrelevant.

Re: The long tail of MD5

#30

Post by ChuckMcM »

smackfu wrote: post #27
jonstewart wrote: post #16

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.

Do the security problems with MD5 make it bad as a hashing algorithm?

Generally the tuple (,) is unique since the attacks on MD5 all involve changing the number of octets in the hashed source. That said, it isn't secure if you can change the length independently of changing the hash. Hence the challenge of using it cryptographically. If you're confident you know the correct 'length' value (acts as a sort of openly shared secret in this case) then you trust the hash.
Post reply on HN