Timeline for Key Derivation Functions vs. Password Hashing Schemes
Current License: CC BY-SA 4.0
14 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Oct 2, 2020 at 21:47 | comment | added | Gilles 'SO- stop being evil' | This explains the difference between a fast KDF and a key stretching KDF, but not the difference between a key stretching KDF and a password hashing function. | |
May 26, 2019 at 15:45 | comment | added | Maarten Bodewes♦ | OK, so I merged the questions, but please next time answer the old question; it doesn't make too much sense to me to close an old question in favor of the new one. | |
May 21, 2019 at 18:09 | vote | accept | cryptopathe | ||
May 21, 2019 at 17:46 | comment | added | cryptopathe | OK, got your point, that is actually well discussed in Section 5 of the HKDF paper. Of course, you didn't claim that Krawczyk proof is incorrect, I'd like to apologize about my wording in the above comment. So, to summarize, publicly-salted-HMAC is actually emulating a (computational) random oracle in the extract phase. Thank you much for your patience and the explanations! | |
May 21, 2019 at 17:33 | comment | added | Squeamish Ossifrage | If you have a uniform random secret salt, then it satisfies the criteria of the PRF. But if you had that, you wouldn't need HKDF-Extract! So while that may technically satisfy the criteria of some theorem justifying security, it doesn't justify security of HKDF-Extract(salt='', DH(...)). The RFC doesn't discuss PRFs at all, because PRF security is not relevant to HKDF-Extract. Neither does the paper discuss PRF security for HKDF-Extract; it is relevant only to HKDF-Expand. The main practical purpose of the salt is to mitigate multi-target attacks. | |
May 21, 2019 at 17:27 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Expand on how PBKDF2 really fails for subkey derivation.
|
May 21, 2019 at 17:24 | comment | added | cryptopathe | According to the HKDF paper, the salt plays the role of the PRF randomness in the extraction phase and is supposed to be "random". There is even a whole section (§3.1) in the RFC that discusses this point and mentions that "even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material". So, you are free to claim that Krawczyk proof of HKDF security is wrong, but I will not follow you on that track ;-) | |
May 21, 2019 at 17:19 | comment | added | Squeamish Ossifrage | Also Lemma 2 of the HKDF paper is about random oracles, not about PRFs, which is exactly the point. | |
May 21, 2019 at 17:13 | comment | added | Squeamish Ossifrage | A PRF may serve as a randomness extractor, but that's not sufficient to justify the security of, e.g., HKDF-Extract(salt, DH(...)), where neither input—not the merely distinct salt, not the nonuniform DH secret—is uniformly distributed and therefore neither input satisfies the criteria of a PRF key. | |
May 21, 2019 at 17:11 | comment | added | cryptopathe | Your first sentence is misleading: the HKDF paper (Lemma 2) proves that a PRF is a sufficiently good randomness extractor, so it's incorrect to say that one needs "more than just PRF security", since PRF security is sufficient, but maybe not necessary. | |
May 21, 2019 at 17:01 | comment | added | Squeamish Ossifrage | HKDF-Extract relies on more than just PRF security of, e.g., HMAC-SHA256, because neither input (salt, IKM) is necessarily uniformly distributed; HKDF-Expand relies only on PRF security. And yes, you can use Argon2 to produce as many output bytes as you want, but it doesn't provide convenient labeling for fast reproducible subkey derivation as a separate step. | |
May 21, 2019 at 16:59 | comment | added | cryptopathe | Another point that puzzles me is that this answer suggests to use Argon2 only as a low-min-entropy extractor, but not as an expander, although Argon2 offer the possibility to generate as many output bytes as necessary. | |
May 21, 2019 at 16:53 | comment | added | cryptopathe | So, you essentially answered my question by "yes". That said, if you look at the respective designs of HKDF and Argon2, the former requires a PRF for the extraction step, while the latter contents itself with a hash function. So, clearly, the extraction phases in both designs do not seem to target the same security requirements. This is something that had not caught my eye during the PHC period. | |
May 21, 2019 at 15:20 | history | answered | Squeamish Ossifrage | CC BY-SA 4.0 |