> (fast in hardware, fast in software, fast in SIMD, whatever)
"Slow to compute in GPUs" has been another design criterion for a while. It helps against brute force attacks. Of course, you might want your hash to be fast on GPUs too, if you're trying to accelerate something, bu cryptographic hashes usually aim for attack resistance.
No, no, no. That's a criteria for password hashes, which are a totally different construction than standard cryptographic hashes. You can't brute force a cryptographic hash, practically by definition.
I must have conflated Keccak's "slow without specific hardware/extensions" with "slow on purpose against GPUs". Both are similar (why would a GPU have an operation for cryptography?) but obviously not the same thing.
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.
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.
"Slow to compute in GPUs" has been another design criterion for a while. It helps against brute force attacks. Of course, you might want your hash to be fast on GPUs too, if you're trying to accelerate something, bu cryptographic hashes usually aim for attack resistance.