5 ms·

"Cryptographic hash" has been used to refer to non-invertable hash functions since the late 70s. Using that term to refer to a KDF is exceptionally misleading

"Cryptographic hash" has been used to refer to non-invertable hash functions since the late 70s. Using that term to refer to a KDF is exceptionally misleading and foolish. If you gave that answer to those PHP developers, they'd come out thinking MD5 and a salt would Work Just Fine.

sarciszewski 12y ago
Point of order: The post you replied to was not "as wrong" as the participants in that forum ;)
- owenmarshall 12y ago
  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.

sarciszewski 12y ago

Point of order: The post you replied to was not "as wrong" as the participants in that forum ;)

owenmarshall 12y ago
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.