I understand the typical way to use HKDF is to make one call to HKDF to obtain multiple keys. Is it safe to use HKDF the following way to generate different keys ? If not, why?

key0 = HKDF-extract-and-expand(0 salt, Z(DH key exchange), x co-ordinates of public points as info).

key1 = HKDF-expand(key0, info1)
key2 = HKDF-expand(key1, info2)

Also, is it safe to replace HKDF-expand for key1 and key2 with sp800-108 or HMAC_SHA256(key0, counter)? i'm curious if there are any subtle differences between them that make them not interchangeable ?


1 Answer 1


It's not necessarily unsafe to create keys that way, but:

  1. the x-coordinates of the public key are already used for calculating Z, so I don't see why inclusion in the KDF makes any difference;
  2. without the x-coordinates, you may as well use HKDF-extract only to derive key0;
  3. key2 is now derived from key1, while it is better to derive them both from key0.

As for point 3, there is no need for the security of key2 to rely on both key0 and key1.

Generally KDF's are interchangeable and even less well studied ones commonly use one-way functions such as hash algorithms with well distributed pseudo random output. However, HKDF comes with 2 advantages:

  1. a more rigorous security proof and;
  2. a split between extract and expand.

It would make sense to use it for those reasons.

  • $\begingroup$ Thank you! Makes sense. Some follow up questions. 1) The reason for using the x-coordinates is due the recommendation in section 5.8.2 of NIST SP800-56A. Are you suggesting this is not necessary or am i misreading the recommendation ? 2) Understood. 3) Can you elaborate on why it is better to derive key2 and key1 from key0 ? Is it because of “there is no need for the security of key2 to rely on both key0 and key1”? $\endgroup$
    – Raghu
    Commented Feb 4, 2019 at 1:50
  • $\begingroup$ 1) I don't see any mention that the X coordinate needs to be used within the KDF in 5.8.2, can you quote? 3) yes, I mainly split it into two sentences as together they made point 3 hard to read :) $\endgroup$
    – Maarten Bodewes
    Commented Feb 4, 2019 at 3:09
  • $\begingroup$ 1) Doesnt say x coordinate "needs to be used", but 5.8.2 says "Failure to adequately bind the derived keying material to the transaction context could adversely affect the types of assurance that can be provided by certain key-agreement schemes". Right after that it says the context specific infromation that can be included in FixedInfo includes "The public keys contributed by each party to the key-agreement transaction". This is followed in many places, notably in the TPM architecture specification "". It is possible they are using it for some other specific reason... $\endgroup$
    – Raghu
    Commented Feb 4, 2019 at 17:58
  • 1
    $\begingroup$ The (Other)Info is used as derivation data that is specific to the output key material rather than info about the input key material. In other words, it should differ for each output keying material that you derive from the input keying material. The X coordinate is already included through Z, so I don't see any reason to add it again. If you want to verify all previous messages including the public key that was send then you can do that using a MAC with one of the output keys (like TLS does). $\endgroup$
    – Maarten Bodewes
    Commented Feb 4, 2019 at 18:24
  • 1
    $\begingroup$ There is no real difference between OtherInfo and Info, as far as I know; Info makes more sense I guess, because OtherInfo begs the question: other than what? The input keying material or possibly a counter? I guess that those are separate from Info is clear from context. But maybe not, given your followup questions :) $\endgroup$
    – Maarten Bodewes
    Commented Feb 4, 2019 at 18:28

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.