[annnnd]

Genuinly curious: isn't the whole point of cryptographic hash functions that they are slow by design, so that they can't be made faster?

[bonzini]

No, you're confusing them with password hashing functions (bcrypt, scrypt) and password-based key derivation functions (PBKDF1, PBKDF2). These _are_ cryptographic hash functions, but they are designed to iterate many many times (the exact number is customizable) in order to take a given amount of time.

"Generic" cryptographic hash functions like SHA-1/SHA-2/SHA-3 (or BLAKE, or MD5) don't iterate more times than is necessary for security, and are designed to be as fast as possible. This way, you can hash multi-gigabyte documents in a fraction of a second.

[annnnd]

Thank you for the clarification!

[baby]

No good hash functions are usually fast. You're talking about "password hashing function", and I can understand the confusion. Maybe if people decided to rename these "pash" it would be easier.

Anyway the state of the art here is Argon2 which won the latest password hashing competition: https://password-hashing.net/

[vertex-four]

Your "password hashing functions" have another name already - KDFs, or key derivation functions.

[phire]

For passwords, yes. You want your hash function to be as slow as possible to reduce the impact of brute force attacks.

But for all other cryptographic purposes like message integrity checking, file verification, signing, or fingerprinting speed is extremely important.

In these cases, the input to the hash is generally public, so there is no reason to even try bruteforcing. And even if you did, these inputs are much longer than passwords.

[detaro]

No. Slow is primarily important for password hashes/key stretching, so specialized algorithms exist for those.

General cryptographic hash functions should not be slow, since in many scenarios they are used on a lot of data and slowness has no security benefits.