Skip to content

Comment on Revisiting the “Cookieless Domain” Recommendationparent

Comments

No. This is bad advice, do not do this; it comes up every time there's a problem with a hash algorithm. The equivalent number of bits in a hashing algorithm designed as such (e.g. sha-384) will be substantially more secure than sha256+md5.

That's not the point.

The point is that you don't want to stand on only one leg when a flaw in that leg may be discovered in the future.

Admittedly MD5 was a poor example from me in that light...

A more realistic mix might be: sha256+RIPEMD160+Whirlpool.

Or, in crypto-speak: Concatenating outputs from multiple hash functions provides collision resistance as good as the strongest of the algorithms included in the concatenated result. [1]

[1] http://en.wikipedia.org/wiki/Cryptographic_hash_function#Con...

Even a very serious attack against SHA-512 would be unlikely to render it as weak as RIPEMD-160 (compare even e.g. MD4, which is pretty thoroughly broken but the attacks still take compute time). If you have the bits, it's better to spend them on a longer hash rather than more hashes.

Even a very serious attack against SHA-512 would

What makes you think you can predict the consequences of an attack against SHA-512?

Don't put all your eggs in one basket.

What makes you think you can predict the consequences of an attack against SHA-512?

70 years of cryptographic history.

Don't put all your eggs in one basket.

Don't use cryptographic primitives in ways they weren't designed for. That's a surefire recipe for disaster.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.