RFC 5869

HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

📅 published May 2010, from ietf

RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 🎀

okay bestie, let's get into it! 💖 this one is from May 2010, and the authors are H. Krawczyk (IBM Research) and P. Eronen (Nokia). It's Informational, so it's published for information and isn't a Standards Track spec. The header doesn't list anything it obsoletes or updates, and the body says it doesn't change any existing specs. 🦋

Abstract ✨

okay so this document specifies a simple HMAC-based key derivation function called HKDF 🔑. HMAC is the [HMAC] thing under the hood. HKDF is meant to be a building block that different protocols and apps can use, and it covers a wide range of needs. It's also super conservative about how much it leans on cryptographic hash functions 💅.

Status of This Memo 🌸

this is NOT an Internet Standards Track spec, it's just published for info 🙈. It's a product of the IETF, so it represents the community's consensus, got public review, and was approved by the IESG. Not every IESG-approved doc is up for any level of Internet Standard though, see Section 2 of RFC 5741 for that. For the current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc5869.

Copyright Notice 🌈

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Read those carefully because they spell out your rights and restrictions. Code extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and it's provided without warranty as described in that license. ⭐

1. Introduction ✨

so a key derivation function (KDF) is a basic, essential piece of cryptographic systems 🔐. Its whole job is to take some initial keying material and turn it into one or more cryptographically strong secret keys 🧚.

This document specifies a simple HMAC-based [HMAC] KDF called HKDF, which is a building block for protocols and apps. It's already used in several IETF protocols, including [IKEv2], [PANA], and [EAP-AKA]. The point is to document this KDF in a general way so future protocols can adopt it easily, and to discourage a proliferation of different KDF mechanisms 💜. It's not a call to change existing protocols, and it doesn't change or update existing specs that use this KDF.

HKDF follows the "extract-then-expand" paradigm, which means the KDF logically has two modules 🎀. The first stage takes the input keying material and "extracts" a fixed-length pseudorandom key K from it. The second stage "expands" K into several more pseudorandom keys, and those are the KDF's output 🦋.

In lots of apps, the input keying material isn't necessarily uniformly distributed. The attacker might have some partial knowledge of it (like a Diffie-Hellman value computed by a key exchange protocol), or even partial control of it (as in some entropy-gathering apps) 😭. So the goal of the "extract" stage is to "concentrate" the possibly dispersed entropy of the input keying material into a short but cryptographically strong pseudorandom key. In some apps the input may already be a good pseudorandom key. In those cases the "extract" stage isn't needed, and "expand" can be used alone ✨.

The second stage "expands" the pseudorandom key to the length you want. How many output keys you get, and how long they are, depends on the specific crypto algorithms that need the keys 🍓.

Some existing KDF specs, like NIST Special Publication 800-56A [800-56A], NIST Special Publication 800-108 [800-108], and IEEE Standard 1363a-2004 [1363a], either only consider the second stage (expanding a pseudorandom key) or don't explicitly separate "extract" from "expand". That often causes design shortcomings 💀. The goal of this spec is to cover a wide range of KDF requirements while minimizing assumptions about the underlying hash function. The "extract-then-expand" paradigm supports that goal really well (see [HKDF-paper] for more on the design rationale) 👑.

2. HMAC-based Key Derivation Function (HKDF) 🌸

2.1. Notation 💖

HMAC-Hash denotes the HMAC function [HMAC] instantiated with hash function 'Hash'. HMAC always takes two arguments: the first is a key and the second is an input (or message). (Note that in the extract step, 'IKM' is used as the HMAC input, not as the HMAC key.)

When the message is made of several elements, we use concatenation (denoted |) in the second argument. For example, HMAC(K, elem1 | elem2 | elem3).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 🫶.

2.2. Step 1: Extract 🔥

Here's the extract step's signature and shape 👇

HKDF-Extract(salt, IKM) -> PRK

Options:
   Hash     a hash function; HashLen denotes the length of the
            hash function output in octets

Inputs:
   salt     optional salt value (a non-secret random value);
            if not provided, it is set to a string of HashLen zeros.
   IKM      input keying material

Output:
   PRK      a pseudorandom key (of HashLen octets)

The output PRK is calculated like this:

PRK = HMAC-Hash(salt, IKM)

2.3. Step 2: Expand 🧚

Now the expand step 💅

HKDF-Expand(PRK, info, L) -> OKM

Options:
   Hash     a hash function; HashLen denotes the length of the
            hash function output in octets

Inputs:
   PRK      a pseudorandom key of at least HashLen octets
            (usually, the output from the extract step)
   info     optional context and application specific information
            (can be a zero-length string)
   L        length of output keying material in octets
            (<= 255*HashLen)

Output:
   OKM      output keying material (of L octets)

The output OKM is calculated as follows:

N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T

where:
T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
...

(where the constant concatenated to the end of each T(n) is a single octet.) 🦋

3. Notes to HKDF Users 💜

this section is a set of guiding principles for using HKDF 📝. A much more extensive account of these principles and the design rationale is in [HKDF-paper], so go read that if you're nerdy like me 🤓.

3.1. To Salt or not to Salt 🧂

HKDF is defined to work with and without a random salt 🙌. That's so it can handle apps where a salt value isn't available. We really want to stress, though, that using salt adds a lot to HKDF's strength. It ensures independence between different uses of the hash function, supports "source-independent" extraction, and strengthens the analytical results that back the HKDF design 🔥.

Random salt is different from the initial keying material in two big ways: it's non-secret and it can be re-used 🎀. That means lots of apps can have access to salt values. For example, a PRNG that constantly produces outputs by applying HKDF to renewable pools of entropy (like sampled system events) can fix a salt value and use it for many HKDF applications, without having to protect the salt's secrecy 🦋. In another domain, a key agreement protocol that derives crypto keys from a Diffie-Hellman exchange can derive a salt from public nonces that get exchanged and authenticated between the parties as part of the agreement. That's the approach taken in [IKEv2] ✨.

Ideally, the salt is a random (or pseudorandom) string of length HashLen 💖. But even a lower-quality salt (shorter, or with limited entropy) can still make a significant contribution to the security of the output keying material. So designers of apps are encouraged to provide salt values to HKDF whenever the app can get them 🫶.

It's worth noting that, while it's not the typical case, some apps may even have a secret salt value available 🤫. In that case HKDF gives an even stronger security guarantee. One example is IKEv1 in its "public-key encryption mode", where the "salt" for the extractor is computed from nonces that are secret. Similarly, IKEv1's pre-shared mode uses a secret salt derived from the pre-shared key 👑.

3.2. The 'info' Input to HKDF 🌈

the 'info' value is optional in the HKDF definition, but it's often super important in apps 💅. Its main job is to bind the derived key material to application- and context-specific information. For example, 'info' might contain a protocol number, algorithm identifiers, user identities, and so on. In particular, it can stop the same keying material from being derived for different contexts when the same input keying material (IKM) is used in those contexts 🧚. It can also take in additional inputs to the expand part if you want. For instance, an app might want to bind the key material to its length L, which makes L part of the 'info' field 🍓. There's one technical requirement for 'info': it should be independent of the input keying material value IKM ⭐.

3.3. To Skip or not to Skip 🦋

in some apps, the input keying material IKM might already be a cryptographically strong key. For example, the premaster secret in TLS RSA cipher suites would be a pseudorandom string, except for the first two octets 🙈. In that case you can skip the extract part and use IKM directly to key HMAC in the expand step. On the other hand, apps may still use the extract part for compatibility with the general case. In particular, if IKM is random (or pseudorandom) but longer than an HMAC key, the extract step can output a suitable HMAC key. (With HMAC, this shortening via the extractor isn't strictly necessary, since HMAC is defined to work with long keys too.) 💜

⚠️ Heads up: if the IKM is a Diffie-Hellman value, like in TLS with Diffie-Hellman, then the extract part SHOULD NOT be skipped! Skipping it would mean using the Diffie-Hellman value g^{xy} itself as the key PRK for HMAC. g^{xy} is NOT a uniformly random or pseudorandom string, so that's a no-go 💀. Instead, HKDF should apply the extract step to g^{xy} (preferably with a salt value), and then use the resulting PRK as a key to HMAC in the expansion part 🔐.

In the case where the amount of required key bits, L, is no more than HashLen, you could use PRK directly as the OKM. This is NOT RECOMMENDED 🙅‍♀️, especially because it would skip using 'info' as part of the derivation. (Adding 'info' as an input to the extract step isn't advisable either. See [HKDF-paper] for why.) 🌸

3.4. The Role of Independence ✨

okay so the whole analysis of key derivation functions assumes that the input keying material (IKM) comes from some source modeled as a probability distribution over bit streams of a certain length 🎲 (like streams from an entropy pool, or values derived from Diffie-Hellman exponents chosen at random). every single instance of IKM is just one sample from that distribution. 🧚

a major goal of KDFs is to make sure that when you apply the KDF to any two values, IKM and IKM', sampled from the (same) source distribution, the resulting keys OKM and OKM' are essentially independent of each other, either statistically or computationally. 💖 to get there, it's important that the inputs to the KDF are selected from appropriate input distributions, and that the inputs are chosen independently of each other. technically, that means each sample needs sufficient entropy, even when you condition on the other inputs to the KDF. main character energy for entropy 👑

independence matters for the salt value too 🧂 there's no need to keep the salt secret, and the same salt value can be used with multiple IKM values. but it's assumed that salt values are independent of the input keying material. so an application needs to make sure that salt values are not chosen or manipulated by an attacker. 🚫

the attacker thing is the big one, bestie 😭 consider the case (like in IKE) where the salt is derived from nonces supplied by the parties in a key exchange protocol. before the protocol can use that salt to derive keys, it needs to make sure those nonces are authenticated as coming from the legitimate parties, and not selected by the attacker. (in IKE, for example, this authentication is an integral part of the authenticated Diffie-Hellman exchange.) iykyk 🔐

4. Applications of HKDF 🌈

okay, HKDF is built for a whole bunch of KDF applications 🦋 like building pseudorandom generators out of imperfect sources of randomness (such as a physical random number generator (RNG)), and generating pseudorandomness from weak sources of randomness, like entropy collected from system events or a user's keystrokes. it also covers deriving cryptographic keys from a shared Diffie-Hellman value in a key-agreement protocol, deriving symmetric keys from a hybrid public-key encryption scheme, key derivation for key-wrapping mechanisms, and more 💅 every one of these can benefit from HKDF's simplicity and multi-purpose nature, plus its analytical foundation. ✨

that said, it's anticipated that some applications won't be able to use HKDF "as-is" because of specific operational requirements 🙈 or they'll be able to use it, just without the full benefits of the scheme. one big example is deriving cryptographic keys from a source of low entropy, like a user's password. the extract step in HKDF can concentrate existing entropy, but it cannot amplify entropy. so, not me trying to make a password magically stronger 💀

for password-based KDFs, the main goal is to slow down dictionary attacks using two ingredients: a salt value, and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of a salt 🧂 but a slowing-down mechanism is not part of this specification. if you're interested in a password-based KDF, you should consider whether [PKCS5] meets your needs better than HKDF does. 🫶

5. Security Considerations 🔐

in spite of how simple HKDF is, there are a LOT of security considerations that went into its design and analysis 😭 an exposition of all of these aspects is beyond the scope of this document. please check out [HKDF-paper] for the detailed info, including the rationale for the design and for the guidelines in Section 3.

a major effort has been made in the paper above, [HKDF-paper], to provide a cryptographic analysis of HKDF as a multi-purpose KDF. it takes a lot of care in how it uses cryptographic hash functions, which is seriously important given how limited our confidence is in the strength of current hash functions. 🚨 this analysis, however, does NOT imply the absolute security of any scheme. it depends heavily on the strength of the underlying hash function and on modeling choices. 💀 still, it's a strong indication of the correct structure of the HKDF design, and of its advantages over other common KDF schemes. 👑

6. Acknowledgments 🎀

the authors would like to thank members of the CFRG (Crypto Forum Research Group) list for their useful comments, and Dan Harkins for providing test vectors. 🫶🌸

7. References 📚

7.1. Normative References

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[SHS] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008.

7.2. Informative References

[1363a] Institute of Electrical and Electronics Engineers, "IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques", IEEE Std 1363a-2004, 2004.
[800-108] National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, November 2008.
[800-56A] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007.
[EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009.
[HKDF-paper] Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 (to appear), 2010, <http://eprint.iacr.org/2010/264>.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.

Appendix A. Test Vectors 🧪

this appendix provides test vectors for the SHA-256 and SHA-1 hash functions [SHS]. the vectors are below, so you can check your implementation. 💖

A.1. Test Case 1

basic test case with SHA-256 🍓

Hash = SHA-256
IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = 0x000102030405060708090a0b0c (13 octets)
info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)
L    = 42

PRK  = 0x077709362c2e32df0ddc3f0dc47bba63
       90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets)
OKM  = 0x3cb25f25faacd57a90434f64d0362f2a
       2d2d0a90cf1a5a4c5db02d56ecc4c5bf
       34007208d5b887185865 (42 octets)

A.2. Test Case 2

test with SHA-256 and longer inputs/outputs 🌊

Hash = SHA-256
IKM  = 0x000102030405060708090a0b0c0d0e0f
       101112131415161718191a1b1c1d1e1f
       202122232425262728292a2b2c2d2e2f
       303132333435363738393a3b3c3d3e3f
       404142434445464748494a4b4c4d4e4f (80 octets)
salt = 0x606162636465666768696a6b6c6d6e6f
       707172737475767778797a7b7c7d7e7f
       808182838485868788898a8b8c8d8e8f
       909192939495969798999a9b9c9d9e9f
       a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)
info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
       c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
       d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
       e0e1e2e3e4e5e6e7e8e9eaebecedeeef
       f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)
L    = 82

PRK  = 0x06a6b88c5853361a06104c9ceb35b45c
       ef760014904671014a193f40c15fc244 (32 octets)
OKM  = 0xb11e398dc80327a1c8e7f78c596a4934
       4f012eda2d4efad8a050cc4c19afa97c
       59045a99cac7827271cb41c65e590e09
       da3275600c2f09b8367793a9aca3db71
       cc30c58179ec3e87c14c01d5c1f3434f
       1d87 (82 octets)

A.3. Test Case 3

test with SHA-256 and zero-length salt/info 🫧

Hash = SHA-256
IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L    = 42

PRK  = 0x19ef24a32c717b167f33a91d6f648bdf
       96596776afdb6377ac434c1c293ccb04 (32 octets)
OKM  = 0x8da4e775a563c18f715f802a063c5a31
       b8a11f5c5ee1879ec3454e5f3c738d2d
       9d201395faa4b61a96c8 (42 octets)

A.4. Test Case 4

basic test case with SHA-1 🌸

Hash = SHA-1
IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets)
salt = 0x000102030405060708090a0b0c (13 octets)
info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)
L    = 42

PRK  = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets)
OKM  = 0x085a01ea1b10f36933068b56efa5ad81
       a4f14b822f5b091568a9cdd4f155fda2
       c22e422478d305f3f896 (42 octets)

A.5. Test Case 5

test with SHA-1 and longer inputs/outputs 🦋

Hash = SHA-1
IKM  = 0x000102030405060708090a0b0c0d0e0f
       101112131415161718191a1b1c1d1e1f
       202122232425262728292a2b2c2d2e2f
       303132333435363738393a3b3c3d3e3f
       404142434445464748494a4b4c4d4e4f (80 octets)
salt = 0x606162636465666768696a6b6c6d6e6f
       707172737475767778797a7b7c7d7e7f
       808182838485868788898a8b8c8d8e8f
       909192939495969798999a9b9c9d9e9f
       a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)
info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
       c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
       d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
       e0e1e2e3e4e5e6e7e8e9eaebecedeeef
       f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)
L    = 82

PRK  = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets)
OKM  = 0x0bd770a74d1160f7c9f12cd5912a06eb
       ff6adcae899d92191fe4305673ba2ffe
       8fa3f1a4e5ad79f3f334b3b202b2173c
       486ea37ce3d397ed034c7f9dfeb15c5e
       927336d0441f4c4300e2cff0d0900b52
       d3b4 (82 octets)

A.6. Test Case 6

test with SHA-1 and zero-length salt/info 🌙

Hash = SHA-1
IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L    = 42

PRK  = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets)
OKM  = 0x0ac1af7002b3d761d1e55298da9d0506
       b9ae52057220a306e07b6b87e8df21d0
       ea00033de03984d34918 (42 octets)

A.7. Test Case 7

test with SHA-1, salt not provided (defaults to HashLen zero octets), zero-length info 🧚

Hash = SHA-1
IKM  = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets)
salt = not provided (defaults to HashLen zero octets)
info = (0 octets)
L    = 42

PRK  = 0x2adccada18779e7c2077ad2eb19d3f3e731385dd (20 octets)
OKM  = 0x2c91117204d745f3500d636a62f64f0a
       b3bae548aa53d423b0d1f27ebba6f5e5
       673a081d70cce7acfc48 (42 octets)

Authors' Addresses 💌

Hugo Krawczyk
IBM Research
19 Skyline Drive
Hawthorne, NY 10532
USA

EMail: hugokraw@us.ibm.com


Pasi Eronen
Nokia Research Center
P.O. Box 407
FI-00045 Nokia Group
Finland

EMail: pasi.eronen@nokia.com

📦 where this page comes from

ietf: rfc5869 2010-05
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms