3

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.)

Community
  • 1
ispiro
  • 2,005
  • 2
  • 18
  • 29
  • 1
    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. – CodesInChaos Jan 29 '14 at 20:34
  • @CodesInChaos From the second link: PBKDF2 supports the generation of arbitrary amounts of key data. (I'm using Rfc2898DeriveBytes if it matters.) – ispiro Jan 29 '14 at 20:38
  • 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. – CodesInChaos Jan 29 '14 at 20:53
  • @CodesInChaos Thanks. Is there any .net implementation of HKDF (or better yet, of a well designed password based key derivation functions)? – ispiro Jan 29 '14 at 21:02
  • Implementing HKDF-Expand on top of HMAC is pretty easy. – CodesInChaos Jan 29 '14 at 21:05
  • @CodesInChaos I'm searching it now, but can't seem to find anything less technical than this (or just general descriptions like "is a simple HMAC-based KDF...". – ispiro Jan 29 '14 at 21:08
  • I just remembered that I actually implemented HKDF in C# a couple of months ago: https://gist.github.com/CodesInChaos/8710228 – CodesInChaos Jan 30 '14 at 14:58
  • @CodesInChaos Thanks. I just now finished writing my own using the specs and am looking for test vectors. But I only wrote the Expand so the test vectors that are available don't help me. Perhaps I'll write the Extract as well. It looks from your code like that's the simple part. – ispiro Jan 30 '14 at 15:04
  • Actually they do help you. Simply use PRK, info and L as input and check if OKM matches. But extract is a one liner, simply call HMAC(salt, ikm). – CodesInChaos Jan 30 '14 at 15:07
  • @CodesInChaos But anyway - as I wrote in my comments to my new question - now I don't understand why was HKDF-Expand invented at all (since one can simply use any hash). And also: You can convert your comments to answers, as they have been helpful and deserve upvotes. EDIT Thanks for the previous comment. I'll have to try that now. – ispiro Jan 30 '14 at 15:09
  • @CodesInChaos: Do you base your recommendation (not to derive more than the natural output size directly from PBKDF2) primarily on considerations of performance with some impact on security by way of allowing less iterations for a given effort, as pointed in this answer; or do you have some other consideration in mind? – fgrieu Mar 01 '14 at 14:00
  • 1
    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. – owo Mar 02 '14 at 21:44
  • @fgrieu I mainly base it on performance, i.e. on the issue describes in that answer. I also think that being able to specify an arbitrary info string is nice. – CodesInChaos Mar 03 '14 at 09:03

1 Answers1

3

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) || ...$$

K.G.
  • 4,617
  • 16
  • 32
  • 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. – Maarten Bodewes Aug 23 '19 at 02:42
  • 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. – Squeamish Ossifrage Aug 23 '19 at 18:08