3 ms·

A KDF, as your link notes, meets all the properties of a cryptographic hash. The important property it has that other non-cryptographic hashes do not have is s

A KDF, as your link notes, meets all the properties of a cryptographic hash. The important property it has that other non-cryptographic hashes do not have is speed (actually, a lack thereof) and (typically) the ability to tune that speed. If we want "technically correct" points I won't grant them (;-)) because KDFs have a property (slowness) cryptographic hashes do not. It would be technically correct to state that KDFs are strict supersets of cryptographic hashes. Practically speaking, calling a KDF a cryptographic hash is very harmful because the average programmer doesn't have the understanding to make the distinction. It's important to give them two very clearly separated categories - cryptographic hashes are {SHA1, RIPEMD160, ...} and are FAST, KDFs are {scrypt, bcrypt, ...} and are SLOW - and a clear rule that "you MUST always use a KDF to store passwords". If you blur the lines between the two, the average programmer will misunderstand and use the wrong tool for the job.

TheLoneWolfling 12y ago
Alright, so, question. Why would the speed of the hash function make any difference, assuming it's a cryptographic hash? If it's faster, run it for more iterations - if it's slower, run it for less. You pick a maximum time, figure out how many iterations can be run in that time, and go from there. I would have thought that a fast hash function would be better, if anything - as it's potentially already more optimized for current hardware, which means that it's less likely that it will get faster on better hardware. I always thought it was the memory complexity of the hash function that was the difference, not speed. Makes it harder to run on GPUs / ASICs.
- derefr 12y ago
  If you’re iterating the hash function until it’s “sufficiently slow", the result is a (one-off, badly-designed) key-derivation function. That’s how they work.

TheLoneWolfling 12y ago

Alright, so, question. Why would the speed of the hash function make any difference, assuming it's a cryptographic hash? If it's faster, run it for more iterations - if it's slower, run it for less. You pick a maximum time, figure out how many iterations can be run in that time, and go from there. I would have thought that a fast hash function would be better, if anything - as it's potentially already more optimized for current hardware, which means that it's less likely that it will get faster on better hardware. I always thought it was the memory complexity of the hash function that was the difference, not speed. Makes it harder to run on GPUs / ASICs.

derefr 12y ago
If you’re iterating the hash function until it’s “sufficiently slow", the result is a (one-off, badly-designed) key-derivation function. That’s how they work.