Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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

Regarding HKDF (RFC 5869) - HKDF has two steps, extract and expand.

Some answers on this site suggest that you can extract once, and then generate multiple keys from the resulting PRK by multiple invocations of HKDF-expand (with different info strings).

Other answers say this is not how HKDF should be used, and possibly not safe. However, using HKDF-expand to generate a longer key (say, 256 bits) and then splitting it would be ok. (See D.W.'s answer in Which risks are associated with deriving multiple keys from the same DH secret Z? for example).

When I originally read the RFC I got the impression that it is fine to generate multiple keys from the same PRK using different info strings, but re-reading it, I can't see this being substantiated anywhere, i.e., the RFC does not explicitly allow multiple HKDF-expands on the same PRK (and implicitly seems to not support it).


  • can HKDF-expand be used multiple times on the same PRK/HKDF-extract result?
  • if not, is it safe to generate a longer key using expand and split it?
share|improve this question
The original paper (PDF; see D.3 on page 29) seems to imply it's safe to use HKDF multiple times with the same SKM and different "context info" values – Tim McLean Dec 30 '14 at 6:14
up vote 2 down vote accepted

Taken directly from the RFC:

The second stage "expands" the pseudorandom key to the desired
length; the number and lengths of the output keys depend on the
specific cryptographic algorithms for which the keys are needed.

The use of the plural here suggests (at least to me) that yes, it's ok to expand the same PRK several times with different contexts. Can you provide any links (within SE or otherwise) that suggest otherwise?

Also from the RFC, regarding the 'info' parameter of the expand step:

In particular, it may prevent the derivation of the same keying material for different contexts (when the same input key material (IKM) is used in such different contexts).

share|improve this answer
added link to question – Marc Lehmann Jul 19 '13 at 7:13

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.