undefined | Better HN

0 pointshaberman13y ago0 comments

Can you recommend a concise taxonomy of crypto that spells out these kinds of distinctions clearly? I think it would be particularly interesting to see these "X uses Y" (ie. KDF uses secure hash) relationships spelled out, to better understand the "primitives" of crypto and how more specialized functions are built on top of them.

I would never have thought of a password hash as a KDF, because you don't use the key for anything except to compare equality. I also wouldn't have thought that an important property of a KDF is for it to be slow. In the case that you're using a KDF to compute an actual encryption/decryption key, this property does not seem important, because the output (the key) is just as sensitive as the input (the password).

0 comments

2 comments · 2 top-level

JoachimSchipper13y ago

Password hashes and key derivation functions can be totally different - key derivation functions only need to be slow if they're intended for low-entropy input, while password hashes in no way need to maximize entropy (e.g. "bcrypt, then 128 zeroes" is a perfectly fine password hash, but I wouldn't want to use the result as e.g. an AES key.)

In practice, though, it's desirable for password hashes to maximize entropy, which makes them usable as key derivation functions; and the key derivation functions that you usually need take passwords as input.

pbsd13y ago

Not all KDFs need to be slow, but only those that take as input a low-entropy secret (e.g., a password).

j / k navigate · click thread line to collapse