Hacker News Reader

I’m surprised that’s a design crtieria. Being able to calculate hashes quickly is advantageous.

Speeding up hashing by, what, a few orders of magnitude shouldn’t break your ≥ 128 bits of preimage protection, surely?

It depends what the goal of your hashing function is. Pure cryptographic hashes like sha256 want to be cheap to calculate. Slow on GPUs is only a design goal if you're making a password hash function, which is a rather different class of problem to sha256/chacha20 and similar.

I think the commenter you're responding to got a little confused somewhere along the way and conflated cryptographic hashes with password hashing.

EDIT: To be clear, password hashes are also cryptographic hashes - but they're a specific subclass of crypto hashes with different design criteria.

Yes, I did confused the part about Keccak[0] being "slow" to compute without specfic hardware/extensions with it being slow on GPUs as a design goal.

[0] Taking this as an example of newer crpytographic hashes, rather than the "old ones" that were easier/faster to calculate on GPUs.

This is a known technique for password hash protection too. By limiting the usefulness of the GPU, you shield yourself from high speed password crackers in the event your password database is compromised.

Reply on news.ycombinator.com