Skip to content

Comment on Revisiting the “Cookieless Domain” Recommendationparent

Comments

though you could say this about any system that uses hashing. if sha256 or 512 is used, the likelihood of collisions with other functioning code, especially code that would yield useful xss seems impossibly small.

Better yet, use multiple hashes. Finding a simultaneous collision in sha256 and md5 seems pretty unlikely.

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.