Hacker News new | ask | show | jobs
by drakeandrews 4925 days ago
Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
4 comments

Password hashes and general-purpose crypto hashes are not the same thing. If it helps, try using the technical term for the kinds of functions cryptography offers for password hashing: key derivation functions (KDFs).
Hey, that was supposed to be my line!
To expand on what has already been noted: a good place for fast hashing is when you're using hashing millions of objects. For example, if I wanted to parse thousands of feeds and store items using a unique hash as their key, I'd want a fast hash that's collision resistant (for the uniqueness part) and one that's fast (for the millions of objects). With password hashing (KDFs, as tptacek noted), the collision resistance is useful, but we want to keep it fairly slow to avoid being able to brute force attacks.
Slow hashing is usually bad, except for password-derivation functions.
fast hashing is bad for storing one way functions of passwords because it makes them easier to attack and make many guesses about the original value from the transformed value, hence all the noise about using slow "key derivation functions" instead. for all other common use cases, faster is better, all else equal.