Hacker News Reader

General-purpose hash functions should be as efficient as possible. That's why they shouldn't be used for password hashing directly. There are special hash functions (slow, memory-intensive, hard to parallelize) for storing password hashes: https://password-hashing.net/

View on HN

BLAKE wasn't specified as being general purpose and was compared against SHA-3 as being "better" because it's faster. Since SHA-3 does support cryptographic functions, my comment is a reasonable response stating that performance isn't the only metric when choosing a hashing function.

In any context where slower is better, SHA3 is not nearly slow enough.

Your comment (none of them, really) was not at all reasonable, assuming as it did that cryptographic hash is synonymous with password hash.

I didn't make that assumption. I exampled one use of cryptographic hashes as being for password hashing. An example is not the same as saying two things are the same.

For a fast hash, being fast is always better. You were not pointing out that there are other metrics, you were directly contradicting a true statement, that BLAKE being faster makes it better.

There is no use case where you want your super-fast hash to be 50% slower.

With a hash this fast you need to get thousands or more times slower to have any benefits in those specialized use cases.

It's sort of a bathtub curve.

Reply on news.ycombinator.com