Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was reading RFC 2898 and something is not clear to me. When I use PBKDF2 with SHA-256 and I want a derived key with length 32 bytes (the same length as my hash function output), your derived key only exists out 1 block (l = 1) of size hLen = 32 bytes.

This seems trivially, but i want to be very sure! Is this correct?

share|improve this question
up vote 2 down vote accepted

The output length of the F step of PBKDF, i.e. the T_i each are of the size of your hash function's (or actually: your PRF's) output.

So yes, when the desired output size is as large (or smaller) as the hash function output, we have l = 1 and thus only one call to F(P, S, c, 1).

I suppose this is also the most common way to use PBKDF-2, the extension to longer generated key sizes is only included to make the scheme more generally usable.

share|improve this answer
Thank you for the quick and clear response! – 11d060a946665fb769d865f4bbb48c Apr 7 '13 at 16:54
The extension to longer key sizes is useful when the output is going to be an actual encryption key or other non-password storage use. Storing an output longer than native hash size is actively counterproductive (BAD) when the output is a password hash (since the attacker only needs to attack the first block, and you wasted time calculating more than one, thus giving the attacker a [further] speed advantage over you). – Anti-weakpasswords Feb 25 '14 at 5:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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