3
$\begingroup$

When doing password-based encryption, is it OK to create one instance of PBKDF2 from the password, and then use it to create both the AES key and the MAC key? (Or should a new instance of PBKDF2 be created using a different salt or iteration count, for each?)

This answer seems to say this isn't a good idea. While this one seems to say it is. Am I misunderstanding one of them? (Or both.)

(And by the way, the first is marked as a duplicate of a question which deals with an initially strong key, while it itself deals with a simple passphrase.)

Improve this question
$\endgroup$
13
  • 1
    $\begingroup$ You should avoid deriving more than the natural output size direclty PBKDF2. With PBKDF2-HMAC-SHA512 that's enough for two keys, with *-SHA1 it isn't. If you need more key material, use HKDF-Expand on the output of PBKDF2. $\endgroup$
    – CodesInChaos
    Jan 29, 2014 at 20:34
  • $\begingroup$ @CodesInChaos From the second link: PBKDF2 supports the generation of arbitrary amounts of key data. (I'm using Rfc2898DeriveBytes if it matters.) $\endgroup$
    – ispiro
    Jan 29, 2014 at 20:38
  • $\begingroup$ It can, but when you do it might be possible for the attacker to compute it more cheaply than for the defender, since the defender needs the whole output, whereas the attacker might be able to confirm it with only part of the output. This shouldn't happen with well designed password based key derivation functions, but PBKDF2 is not one of those. $\endgroup$
    – CodesInChaos
    Jan 29, 2014 at 20:53
  • $\begingroup$ @CodesInChaos Thanks. Is there any .net implementation of HKDF (or better yet, of a well designed password based key derivation functions)? $\endgroup$
    – ispiro
    Jan 29, 2014 at 21:02
  • 1
    $\begingroup$ Consider scrypt instead of PBKDF2, it handles this very well. There is no “natural output size,” AFAIK. If you want two 256-bit keys, use 512 as the length argument and use bits 0-255 and 256-511 as the two keys. $\endgroup$
    – myfreeweb
    Mar 2, 2014 at 21:44

1 Answer 1

Reset to default
3
$\begingroup$

From a security point of view, deriving lots of key material using PBKDF2 is ok.

From a practical point of view, deriving lots of key material using PBKDF2 is inefficient (in the sense that to generate $n$ blocks and increase the adversary's work by $t$, you do work $nt$, instead of $n+t$).

A more practical solution uses PBKDF2 to generate a short string and a suitable generator (probably HMAC-based) to produce lots of key material. Typically: $$k_0 \leftarrow PBKDF2(pw, \dots)$$ $$\text{key material} \leftarrow HMAC(k_0, 1) || HMAC(k_0, 2) || HMAC(k_0, 3) || ...$$

Improve this answer
$\endgroup$
2
  • $\begingroup$ Generally we try and use a KBKDF such as HKDF instead of a HMAC to generate the additional key material, although HMAC with a counter comes pretty close. $\endgroup$
    – Maarten Bodewes ♦
    Aug 23, 2019 at 2:42
  • $\begingroup$ Deriving lots of key material from PBKDF2 is not OK—it can hurt security. Why? If you draw $n$ blocks of PBKDF2 output, the adversary's cost to find the key can be as little as $1/n$ times what it would have been had you generated one block and fed it through (say) HKDF. In some cases it may not hurt, but these cases have to be analyzed in excruciating detail individually, so it is better to just generate one block and use HKDF to work around this stupid design in PBKDF2. $\endgroup$
    – Squeamish Ossifrage
    Aug 23, 2019 at 18:08

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