3 ms·
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
by orra 5y ago
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?
- jfindley 5y agoIt 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.
- dr_zoidberg 5y agoYes, 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.
- MontagFTB 5y agoThis 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.