5
$\begingroup$

I understand the way $\textrm{PBKDF2}$ can be used to 'stretch' a password/passphrase that does not provide full entropy.

My question: how does one choose the PRF? A common choice is any well-known cryptographic hash like $\textrm{SHA256}$, and I understand why that works. Some systems, however, use $\textrm{HMAC}_{\textrm{SHA256}}$, where the password is used to key the MAC.

Why would one use $\textrm{HMAC}_{\textrm{SHA256}}$ over $\textrm{SHA256}$ as the PRF? I don't see any advantage to this. Surely the weaknesses of Merkle-Dåmgard hashes adressed by $\textrm{HMAC}$ are irrelevant when the password is a secret used to derive another secret?

Improve this question
$\endgroup$
1
  • 4
    $\begingroup$ A PRF has two inputs, a key and a message. A hash has only one. $\endgroup$
    – CodesInChaos
    Commented Jun 1, 2016 at 10:14

1 Answer 1

Reset to default
5
$\begingroup$

HMAC is sometimes called a keyed hash. The key is not part of the input of a secure hash (as CodesInChaos already indicated in the comments). HMAC is a relatively simple construct to allow a key to be used as input to the underlying secure hash. It specifically is constructed to disallow length extension attacks - although those are not likely an issue in PBKDF2.

You could use If you'd use SHA-256 directly you would have to make sure you're not vulnerable against those kind of attacks. You would basically be without the security proofs of HMAC.

KDF1 and KDF2 are KDFs/PRFs that simply concatenate elements in a certain way before entering the result into the hash. SHA-3/KMAC will (largely) be a concatenation of key and message before hashing. So it certainly can be done that way.

You should however reverse your question: Why wouldn't you use a secure PRF instead of directly using a hash?.

HMAC is relatively efficient. Inn PBKDF2 (which requires a work factor / iteration count) the small inefficiencies may actually be a benefit (a good implementation should however store the intermediate hash value of the password, otherwise an attacker may have an advantage).

Furthermore, HMAC is still considered secure, even if the underlying hash is vulnerable to certain kind of attacks (such as those against MD5 and SHA-1).

For the SHA-1 and SHA-2 algorithms I'd advice you to keep to HMAC unless you've got very strong (performance related?) reasons not to.

Improve this answer
$\endgroup$
9
  • 1
    $\begingroup$ I'm still thinking of a way to explain that both KBKDF's and MAC algorithms are PRF's. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 1, 2016 at 11:23
  • 1
    $\begingroup$ Funfact: Many of the recent hash functions (BLAKE, BLAKE2, Skein, ...) have built-in MAC modes which could be a replacement for the full HMAC construction here. $\endgroup$
    – SEJPM
    Commented Jun 1, 2016 at 11:27
  • 1
    $\begingroup$ @SEJPM Yeah, I just kept to the one that (I hope) becomes standardized in the answer. I could have included a lot of other MAC and KDF constructions as well. Feel free to post them as fun-facts :) $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 1, 2016 at 12:07
  • 1
    $\begingroup$ DiscobarMolokai: I presumed you understood about them from your question, but answers should be written with a large audience in mind. Welcome to crypto, by the way! $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 1, 2016 at 12:08
  • 2
    $\begingroup$ Do you have a good example of how length extension attacks or collision attacks might be turned into PBKDF2 exploits? I presume certain rainbow table computations might be slightly easier, but perhaps you have a really good example? $\endgroup$
    – Henrick Hellström
    Commented Jun 1, 2016 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.