NIST Special Publication 800-56C
Revision 2

Recommendation for Key-Derivation
Methods in Key-Establishment Schemes
Elaine Barker
Lily Chen
Richard DavisThis publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-56Cr2

C O M P U T E R

S E C U R I T Y

NIST Special Publication 800-56C
Revision 2

Recommendation for Key-Derivation
Methods in Key-Establishment Schemes
Elaine Barker
Lily Chen
Computer Security Division
Information Technology Laboratory
Richard Davis
National Security Agency

This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-56Cr2

August 2020

U.S. Department of Commerce

Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology
Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

Authority
This publication has been developed by NIST in accordance with its statutory responsibilities under theFederal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law(P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including
minimum requirements for federal information systems, but such standards and guidelines shall not apply
to national security systems without the express approval of appropriate federal officials exercising policy
authority over such systems. This guideline is consistent with the requirements of the Office of Management
and Budget (OMB) Circular A-130.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory andbinding on federal agencies by the Secretary of Commerce under statutory authority. Nor should theseguidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal official. This publication may be used by nongovernmentalorganizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.
National Institute of Standards and Technology Special Publication 800-56C Revision 2
Natl. Inst. Stand. Technol. Spec. Publ. 800-56C Rev. 2, 41 pages (August 2020)
CODEN: NSPUE2This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-56Cr2
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.
There may be references in this publication to other publications currently under development by NIST in accordancewith its assigned statutory responsibilities. The information in this publication, including concepts and methodologies,
may be used by federal agencies even before the completion of such companion publications. Thus, until eachpublication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
planning and transition purposes, federal agencies may wish to closely follow the development of these new
publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
NIST. Many NIST cybersecurity publications, other than the ones noted above, are available athttps://csrc.nist.gov/publications.

Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: 800-56C_Comments@nist.gov
All comments are subject to release under the Freedom of Information Act (FOIA).

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Reports on Computer Systems Technology

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

The Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advance thedevelopment and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-effective security and privacy of other than national security-related information in federal
information systems. The Special Publication 800-series reports on ITL’s research, guidelines, andoutreach efforts in information system security, and its collaborative activities with industry,
government, and academic organizations.
Abstract
This Recommendation specifies techniques for the derivation of keying material from a sharedsecret established during a key-establishment scheme defined in NIST Special Publications 80056A or 800-56B.
Keywords
Expansion; extraction; extraction-then-expansion; hash function; key derivation; key
establishment; message authentication code.

ii

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Acknowledgements
The authors gratefully acknowledge the contributions on this and previous versions of thisdocument by their NIST colleagues (Quynh Dang, Sharon Keller, John Kelsey, Allen Roginsky,
Meltem Sonmez Turan, Apostol Vassilev, and Tim Polk) and by Miles Smid, formerly of Orion
Security Solutions.
The authors also gratefully appreciate the thoughtful and instructive comments received during the
public comment periods, which helped to improve the quality of this publication.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Conformance Testing
Conformance testing for implementations of the functions that are specified in this publication will
be conducted within the framework of the Cryptographic Algorithm Validation Program (CAVP)
and the Cryptographic Module Validation Program (CMVP). The requirements on these
implementations are indicated by the word “shall.” Some of these requirements may be out of
scope for CAVP or CMVP validation testing and are therefore the responsibility of entities using,
implementing, installing, or configuring applications that incorporate this Recommendation.

iii

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESPatent Disclosure Notice
NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims
whose use may be required for compliance with the guidance or requirements of this publication
disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL
calls for patents and ITL has not undertaken a patent search in order to identify which, if any,
patents may apply to this publication.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

As of the date of publication and following call(s) for the identification of patent claims whose use
may be required for compliance with the guidance or requirements of this publication, no suchpatent claims have been identified to ITL.
No representation is made or implied by ITL that licenses are not required to avoid patent
infringement in the use of this publication.

iv

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Table of Contents
1

Introduction ........................................................................................................... 1

2

Scope and Purpose................................................................................................ 2

3

Definitions, Symbols and Abbreviations ............................................................. 3
3.1 Definitions ....................................................................................................... 3
3.2 Symbols and Abbreviations ............................................................................ 8This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

4

One-Step Key Derivation ..................................................................................... 11
4.1 Specification of Key-Derivation Functions..................................................... 11
4.2 The Auxiliary Function H(x) and Related Parameters ................................... 15

5

Two-Step Key Derivation ..................................................................................... 17
5.1 Specification of Key-Derivation Procedure.................................................... 17
5.2 The Auxiliary MAC Algorithm and Related Parameters ................................ 20
5.3 Randomness Extraction followed by Multiple Key Expansions ..................... 21

6

Application-Specific Key-Derivation Methods ................................................... 25

7

Selecting Hash Functions and MAC Algorithms ............................................... 26

8

Further Discussion .............................................................................................. 28
8.1 Using a Truncated Hash Function................................................................. 28
8.2 The Choice of a Salt Value ........................................................................... 28
8.3 MAC Algorithms used for Extraction and Expansion..................................... 28
8.4 Destruction of Sensitive Locally Stored Data ................................................ 29

References ................................................................................................................... 30
Appendix A: Revisions (Informative)......................................................................... 32
A.1 The Original Version of SP 800-56C ............................................................. 32
A.2 Revision 1 ..................................................................................................... 32
A.3 Revision 2 ..................................................................................................... 32v

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

List of Figures
Figure 1: The Extraction-then-Expansion Key-Derivation Procedure ................. 17
Figure 2: Randomness Extraction followed by Multiple Key Expansions ........... 22
List of Tables
Table 1: H(x) = hash(x) (Option 1) ...................................................................... 15
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Table 2: H(x) = HMAC-hash(salt, x) (Option 2) .................................................... 15
Table 3: H(x) = KMAC#(salt, x, H_outputBits, “KDF”) (Option 3) ......................... 16
Table 4: MAC( salt, Z, …) = HMAC-hash( salt, Z ) (For Randomness Extraction) ... 20
Table 5: MAC( salt, Z, …) = AES-N-CMAC( salt, Z ) (For Randomness Extraction). 21

vi

NIST SP 800-56C REV. 2

1

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESIntroduction

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

During the execution of a public key-based key-establishment scheme specified in either of the
National Institute of Standards and Technology (NIST) Special Publications [SP 800-56A] 1 or [SP
800-56B], 2 a key-derivation method may be required to obtain secret cryptographic keying
material. This Recommendation specifies the key-derivation methods that can be used, as needed,in those key-establishment schemes. The keying material derived using these methods shall becomputed in its entirety before outputting any portion of it and shall only be used as secret keying
material, such as a symmetric key used for data encryption or message integrity, a secretinitialization vector, or, perhaps, a key-derivation key that will be used to generate additional
keying material (possibly using a different derivation process; see [SP 800-108] 3). The derived
keying material shall not be used as a key stream for a stream cipher.

1

SP 800-56A, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography

2

SP 800-56B, Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography

3

SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions (Revised)

1

NIST SP 800-56C REV. 2

2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Scope and Purpose

This Recommendation specifies two categories of key-derivation methods that can be employed,
as required, to derive keying material from a shared secret Z generated during the execution of a
key-establishment scheme specified in [SP 800-56A] or [SP 800-56B].

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

In addition to the currently approved techniques for the generation of the shared secret Z as
specified in SP 800-56A and SP 800-56B, this Recommendation permits the use of a “hybrid”
shared secret of the form Z′ = Z || T, a concatenation consisting of a “standard” shared secret Z thatwas generated during the execution of a key-establishment scheme (as currently specified in [SP
800-56A] or [SP 800-56B]) followed by an auxiliary shared secret T that has been generated using
some other method. The content, format, length, and method used to generate T must be known
and agreed upon by all parties that will rely upon the derived keying material, as well as by any
agents trusted to act on their behalf. The key-derivation methods specified in this Recommendation
will process a hybrid Z′ in the same way they process a standard Z. Therefore, for simplicity ofnotation and exposition, any shared secret denoted by the symbol Z in the remainder of thisRecommendation can be of either the “standard” or “hybrid” variety.
The first category of specified key-derivation methods consists of a family of one-step keyderivation functions that derive keying material of a desired length from a shared secret that was
generated during the execution of a key-establishment scheme (and possibly other information aswell).
The second category consists of an extraction-then-expansion key-derivation procedure thatinvolves two steps:
1) Randomness extraction, to obtain a single cryptographic key-derivation key from a sharedsecret generated during the execution of a key-establishment scheme.
2) Key expansion, to derive keying material of the desired length from that key-derivation
key and other information. Since NIST’s [SP 800-108] specifies several families of keyderivation functions that are approved for deriving additional keying material from a given
cryptographic key-derivation key, those functions are employed in the second (keyexpansion) step of these two-step procedures.
In addition to the key-derivation methods whose specifications are provided in this document, [SP
800-135] 4 describes several variants (of both the one-step and two-step methods) that areapproved for specific applications.

4

SP 800-135 Rev. 1, Recommendation for Existing Application-Specific Key Derivation Functions

2

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

3

Definitions, Symbols, and Abbreviations

3.1

Definitions

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Algorithm

A clearly specified mathematical process for computation; a set ofrules that, if followed, will give a prescribed result.

Approved

An algorithm or technique that is either 1) specified in a Federal
Information
Processing
Standard(FIPS)or
NIST
Recommendation, 2) adopted in a FIPS or NIST Recommendation,or 3) specified in a list of NIST-approved security functions.

Big-endian

The property of a byte string having its bytes positioned in order ofdecreasing significance. In particular, the leftmost (first) byte is themost significant (containing the most significant eight bits of thecorresponding bit string), and the rightmost (last) byte is the leastsignificant (containing the least significant eight bits of thecorresponding bit string).
For the purposes of this Recommendation, it is assumed that thebits within each byte of a big-endian byte string are also positioned
in order of decreasing significance (beginning with the mostsignificant bit in the leftmost position and ending with the leastsignificant bit in the rightmost position).

Bit length

The number of bits in a bit string (e.g., the bit length of the string
0110010101000011 is sixteen bits). The bit length of the empty(i.e., null) string is zero.

Bit string

An ordered sequence of bits (represented as 0s and 1s). Unlessotherwise stated in this document, bit strings are depicted as
beginning with their most significant bit (shown in the leftmost
position) and ending with their least significant bit (shown in therightmost position). For example, the most significant (leftmost) bitof 0101 is 0, and its least significant (rightmost) bit is 1. Ifinterpreted as the 4-bit binary representation of an unsigned integer,
0101 corresponds to the number five.

Byte

A bit string consisting of eight bits.

Byte length

The number of consecutive (non-overlapping) bytes in a byte
string. For example, 0110010101000011 = 01100101 || 01000011 is
two bytes long. The byte length of the empty string is zero.

Byte string

An ordered sequence of bytes, beginning with the most significant(leftmost) byte and ending with the least significant (rightmost)3

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

byte. Any bit string whose bit length is a multiple of eight can beviewed as the concatenation of an ordered sequence of bytes (i.e., abyte string). For example, the bit string 0110010101000011 can beviewed as a byte string since it is the concatenation of two bytes:
01100101 followed by 01000011.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Concatenation

As used in this Recommendation, the concatenation X || Y of bit
string X followed by bit string Y is the ordered sequence of bits
formed by appending Y to X in such a way that the leftmost (i.e.,
initial) bit of Y follows the rightmost (i.e., final) bit of X.

Cryptographic key (Key)A parameter used with a cryptographic algorithm that determines
its operation.

Estimated maximum
security strength

An estimate of the largest security strength that can be attained bya cryptographic mechanism given the explicit and implicit
assumptions that are made regarding its implementation andsupporting infrastructure (e.g., the algorithms employed, theselection of associated primitives and/or auxiliary functions, thechoices for various parameters, the methods of generation and/or
protection for any required keys, etc.). The estimated maximum
security strengths of various approved cryptographic mechanisms
are provided in [SP 800-57].

Hash function

A function that maps a bit string of arbitrary length to a fixed-length
bit string. Depending upon the relying application, the security
strength that can be supported by a hash function is typicallymeasured by the extent to which it possesses one or more of thefollowing properties:
1. (Collision resistance) It is computationally infeasible to findany two distinct inputs that map to the same output.
2. (Preimage resistance) Given a randomly chosen target
output, it is computationally infeasible to find any input thatmaps to that output. (This property is called the one-way
property.)
3. (Second preimage resistance) Given one input value, it iscomputationally infeasible to find a second (distinct) input
value that maps to the same output as the first value.
This Recommendation uses the strength of the preimage resistanceof a hash function as a contributing factor when determining thesecurity strength provided by a key-derivation method.

4

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESApproved hash functions are specified in [FIPS 180] 5 and[FIPS 202]. 6This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Key-derivation function

As used in this Recommendation, either a one-step key-derivation
method or a key-derivation function based on a pseudorandomfunction as specified in [SP 800-108].

Key-derivation method

As used in this Recommendation, a process that derives secretkeying material from a shared secret. This Recommendation
specifies both one-step and two-step key-derivation methods.

Key-derivation procedure

As used in this Recommendation, a two-step key-derivation method
consisting of randomness extraction followed by key expansion.

Key-derivation key

As used in this Recommendation, a key that is used during the keyexpansion step of a key-derivation procedure to derive the secret
output keying material. This key-derivation key is obtained from ashared secret during the randomness-extraction step.

Key establishment

A procedure that results in secret keying material that is shared
among different parties.

Key expansion

The second step in the key-derivation procedure specified in thisRecommendation in which a key-derivation key is used to derive
secret keying material having the desired length.

Keying material

Data that is represented as a binary string such that any nonoverlapping segments of the string with the required lengths can beused as secret keys, secret initialization vectors, and other secretparameters.

Message Authentication
Code (MAC) algorithm

A family of cryptographic functions that is parameterized by asymmetric key. Each of the functions can act on input data (calleda “message”) of variable length to produce an output value of a
specified length. The output value is called the MAC of the input
message. MAC(k, x, …) is used to denote the MAC of message x
computed using the key k (and any additional algorithm-specificparameters). An approved MAC algorithm is expected to satisfy
the following property (for each supported security strength):

5 FIPS 180, Secure Hash Standard (SHS)

6FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions

5

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Without knowledge of the key k, it must be computationallyinfeasible to predict the (as-yet-unseen) value of MAC(k, x, …)
with a probability of success that is a significant improvement
over simply guessing either the MAC value or k, even if one has
already seen the results of using that same key to compute
MAC(k, xj, …) for (a bounded number of) other messages xj ≠ x.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

A MAC algorithm can be employed to provide authentication of theorigin of data and/or to provide data-integrity protection. In thisRecommendation, approved MAC algorithms are used todetermine families of pseudorandom functions (indexed by the
choice of key) that may be employed during key derivation.
Nonce

A varying value that has, at most, a negligible chance ofrepeating; for example, a random value that is generated anew foreach use, a timestamp, a sequence number, or some combinationof these.

Pseudorandom function
family (PRF)

An indexed family of (efficiently computable) functions, eachdefined for the same particular pair of input and output spaces. (Forthe purposes of this Recommendation, one may assume that boththe index set and the output space are finite.) The indexed functions
are pseudorandom in the following sense:
If a function from the family is selected by choosing an index
value uniformly at random, and one’s knowledge of theselected function is limited to the output values corresponding
to a feasible number of (adaptively) chosen input values, thenthe selected function is computationally indistinguishable froma function whose outputs were fixed uniformly at random.

Randomness extraction

The first step in the two-step key-derivation procedure specified inthis Recommendation; during this step, a key-derivation key is
produced from a shared secret.

Salt

As used in this Recommendation, a byte string (which may besecret or non-secret) that is used as a MAC key by either: 1) a
MAC-based auxiliary function H employed in one-step key
derivation or 2) a MAC employed in the randomness-extraction
step during two-step key derivation.

Security strength

A number characterizing the amount of work that is expected to
suffice to “defeat” an implemented cryptographic mechanism (e.g.,
by compromising its functionality and/or circumventing theprotection that its use was intended to facilitate). In thisRecommendation, security strength is measured in bits. If the
security strength of a particular implementation of a cryptographic
6

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

mechanism is s bits, it is expected that the equivalent of (roughly)
2s basic operations of some sort will be sufficient to defeat it insome way.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Shared secret

The secret byte string that is computed/generated during theexecution of an approved key-establishment scheme and used as
input to a key-derivation method as part of that transaction.

Shall

A requirement that needs to be fulfilled to claim conformance tothis Recommendation. Note that shall may be coupled with not tobecome shall not.

Support(a security strength)

A security strength of s bits is said to be supported by a particular
choice of algorithm, primitive, auxiliary function, or parameters foruse in the implementation of a cryptographic mechanism if thatchoice will not prevent the resulting implementation from attaining
a security strength of at least s bits.
In this Recommendation, it is assumed that implementation choices
are intended to support a security strength of 112 bits or more (see[SP 800-57] 7 and [SP 800-131A] 8).

Symmetric key

A single cryptographic key that is used with a symmetric-key
algorithm; also called a secret key. A symmetric-key algorithm is a
cryptographic algorithm that uses the same secret key for an
operation and its complement (e.g., encryption and decryption).

Targeted security strength The security strength that is intended to be supported by one ormore implementation-related choices (such as algorithms,
primitives, auxiliary functions, parameter sizes, and/or actual
parameters) for the purpose of implementing a cryptographic
mechanism.

7 SP 800-57 Rev. 4, Recommendation for Key Management Part 1: General8

SP 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths

7

NIST SP 800-56C REV. 2

3.2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Symbols and Abbreviations

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr20x

A marker used to indicate that the following symbols are to beinterpreted as a bit string written in hexadecimal notation (using
the symbols 0, 1, …, 9 and A, B, …, F to denote 4-bit binary
representations of the integers zero through nine and 10 through15, respectively). A byte can be represented by a hexadecimalstring of length two; the leftmost hexadecimal symbol corresponds
to the most significant four bits of the byte, and the rightmost
hexadecimal symbol corresponds to the least significant four bitsof the byte. For example, 0x9D represents the bit string 10011101(assuming that the bits are positioned in order of decreasing
significance).

AES

Advanced Encryption Standard (the block cipher specified in[FIPS 197] 9).

AES-N

The variant of the AES block cipher that requires an N-bit
encryption/decryption key; the three variants specified in [FIPS
197] are AES-128, AES-192, and AES-256.

(N = 128, 192, or 256)
AES-CMAC

The Cipher-based Message Authentication Code (CMAC) modeof operation for the AES block cipher, as specified in [SP 80038B] 10.

AES-N-CMAC(k, x)

An implementation of AES-CMAC based on the AES-N variant of
the AES block cipher (for N = 128, 192, or 256); its output is a
128-bit MAC computed over the “message” x using the key k.

(N = 128, 192, or 256)
counter

An unsigned integer, represented as a big-endian four-byte string,that is employed by the one-step key-derivation method specified
in Section 4.1.

Context

A bit string of context-specific data; a subcomponent of the
FixedInfo that is included as part of the input to the two-step keyderivation method specified in Section 5.1.

default_salt

A default value assigned to salt (if necessary) to implement an
auxiliary function H selected according to Option 2 or 3 in the onestep key-derivation method specified in Section 4.1.

9 FIPS 197, Advanced Encryption Standard

10

SP 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication

8

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

DerivedKeyingMaterial

Keying material that is derived from a shared secret Z (and otherdata) through the use of a key-derivation method.

ECC

Elliptic curve cryptography.

FFC

Finite field cryptography.

FixedInfo

A bit string of context-specific data whose value does not change
during the execution of a key-derivation method specified in thisRecommendation.

H

The auxiliary function used to produce blocks of keying material
during the execution of the one-step key-derivation method specified
in Section 4.1.

hash

A hash function. Approved choices for hash are specified in [FIPS180] and [FIPS 202].

HMAC

Keyed-hash Message Authentication Code, as specified in [FIPS198]. 11

HMAC-hash(k, x)

An implementation of HMAC using the hash function, hash; its
output is a MAC computed over “message” x using the key k.

H_outputBits

A positive integer that indicates the length (in bits) of the output ofeither: 1) the auxiliary function H used in the one-step keyderivation method specified in Section 4.1 or 2) an auxiliary
HMAC algorithm used in the two-step key-derivation method
specified in Section 5.1.

IFC

Integer factorization cryptography.

IV

Initialization vector; as used in this Recommendation, it is a bit
string used as an initial value during the execution of an approved
PRF-based KDF operating in Feedback Mode, as specified in [SP800-108].

KDF

Key-derivation function.

KDK

The key-derivation key resulting from the randomness-extraction
step, which is then used in the key-expansion step during theexecution of the key-derivation procedure specified in Section 5.1.

11

FIPS 198, The Keyed-Hash Message Authentication Code (HMAC)

9

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

KDM

Key-derivation method.

KMAC

Keccak Message[SP 800-185]. 12

KMAC#(k, x, l, S)

A variant of KMAC (either KMAC128 or KMAC256, as specified
in [SP 800-185]); its output is an l-bit MAC computed over the“message” x using the key k and “customization string” S.

LA positive integer specifying the desired length (in bits) of thederived keying material.

[L]2

An agreed-upon encoding of the integer L as a bit string.

MAC

Message Authentication Code.

MAC(k, x, …)

An instance of a MAC algorithm computed over the “message” xusing the key k (and any additional algorithm-specific parameters).

max_H_inputBits

The maximum length (in bits) for strings used as input to theauxiliary function H employed by the one-step key-derivation
method specified in Section 4.1.

OtherInput

A collective term for any and all additional data (other than theshared secret itself) that is used as input to a key-derivation method
specified in this Recommendation.

PRF

Pseudorandom function (family).

s

Security strength (in bits).

SHA

Secure Hash Algorithm, as specified in [FIPS 180] (i.e., SHA-1,
SHA-224, SHA-512/224, SHA-256, SHA-512/256, SHA-384, or
SHA-512) or [FIPS 202] (i.e., SHA3-224, SHA3-256, SHA3-384,
or SHA3-512).

Z

The shared secret (determined as described in Section 2 of thisRecommendation).

12

Authentication

SP 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash

10

Code,

as

specifiedinNIST SP 800-56C REV. 2

4

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESOne-Step Key Derivation

This section specifies a family of approved key-derivation functions (KDFs) that are executed ina single step; a two-step procedure is specified in Section 5. The input to each specified KDF
includes the shared secret Z, an indication of the desired bit length of the keying material to be
output, and, perhaps, other information (as determined by the particular implementation of the keyestablishment scheme and/or key-derivation function).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Implementations of these one-step KDFs depend upon the choice of an auxiliary function H, which
can be either: 1) an approved hash function, denoted as hash, as defined in [FIPS 180] or [FIPS202]; 2) HMAC with an approved hash function, hash, denoted as HMAC-hash and defined in[FIPS 198]; or 3) a KMAC variant, as defined in [SP 800-185]. Tables 1, 2, and 3 in Section 4.2
describe the possibilities for H and also include any restrictions on the associated implementationdependent parameters. H shall be chosen in accordance with the selection requirements specified
in Section 7.
When an approved MAC algorithm (HMAC or KMAC) is used to define the auxiliary function
H, it is permitted to use a known salt value as the MAC key. In such cases, it is assumed that the
MAC algorithm will satisfy the following property (for each of its supported security strengths):
Given knowledge of the key k, and (perhaps) partial knowledge of a message x that includes an
unknown substring y, it must be computationally infeasible to predict the (as-yet-unseen) valueof MAC(k, x, …) with a probability of success that is a significant improvement over simply
guessing either the MAC value or the value of y, even if one has already seen the values ofMAC(kj, xj, …) for a feasible number of other (kj, xj) pairs where each key kj is known and each(partially known) message xj includes the same unknown substring y, provided that none of the(kj, xj) pairs is identical to (k, x).
This property is consistent with the use of the MAC algorithm as the specification of a family ofpseudorandom functions defined on the appropriate message space and indexed by the choice of
MAC key. Under Option 2 and Option 3 of the KDF specification below, the auxiliary function H
is a particular selection from such a family. The (partially known) messages will have the form
counter || Z || FixedInfo, containing the shared secret Z as an unknown substring.
4.1

Specification of Key-Derivation Functions

A family of one-step key-derivation functions is specified as follows:
Function call: KDM( Z, OtherInput).
Options for the Auxiliary Function H:
Option 1: H(x) = hash(x), where hash is an approved hash function meeting the selection
requirements specified in Section 7, and the input, x, is a bit string.
Option 2: H(x) = HMAC-hash(salt, x), where HMAC-hash is an implementation of the HMAC
algorithm (as defined in [FIPS 198]) employing an approved hash function, hash,that meets the selection requirements specified in Section 7. An implementationdependent byte string, salt, whose (non-null) value may be optionally provided in
11

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

OtherInput, serves as the HMAC key, and x (the input to H) is a bit string that serves
as the HMAC “message” as specified in [FIPS 198].
Option 3: H(x) = KMAC#(salt, x, H_outputBits, S), where KMAC# is a particular
implementation of either KMAC128 or KMAC256 (as defined in [SP 800-185]) thatmeets the selection requirements specified in Section 7. An implementationdependent byte string, salt, whose (non-null) value may be optionally provided in
OtherInput, serves as the KMAC# key, and x (the input to H) is a bit string that serves
as the KMAC# “message” as specified in [SP 800-185]. The parameter H_outputBits
determines the bit length chosen for the output of the KMAC variant employed. The“customization string” S shall be the byte string 01001011 || 01000100 || 01000110,
which represents the sequence of characters “K”, “D,” and “F” in 8-bit ASCII. (Thisthree-byte string is denoted by “KDF” in this document.)
Implementation-Dependent Parameters:
1. H_outputBits – A positive integer that indicates the length (in bits) of the output of theauxiliary function H that is used to derive blocks of secret keying material. If Option 1 or
Option 2 is chosen, then H_outputBits corresponds to the bit-length of the output block of
the particular hash function used in the implementation of H; therefore, H_outputBits is in
the set {160, 224, 256, 384, 512} with the precise value determined by the choice for thehash function, hash (see Section 4.2 for details). If Option 3 is chosen, then H_outputBits
shall either be set equal to the length (in bits) of the secret keying material to be derived (seeinput L below) or selected from the set {160, 224, 256, 384, 512}.
2. max_H_inputBits – A positive integer that indicates the maximum permitted length (in bits)of the bit string x that is used as input to the auxiliary function H. If Option 1 or Option 2 ischosen for the implementation of H, then the upper bound on max_H_inputBits shall not
exceed the message limit imposed by the hash function, hash (see Section 4.2 for details);
max_H_inputBits values smaller than a specification-imposed upper bound may be dictatedby the particular use case. If the hash function, hash, is specified in [FIPS 202], or if Option
3 is chosen for the implementation of H, then there is no specification-imposed upper boundon max_H_inputBits; the value assigned to max_H_inputBits may be determined by theneeds of the relying applications/parties.
3. default_salt – A non-null (secret or non-secret) byte string that is needed only if either Option
2 (HMAC-hash) or Option 3 (KMAC#) is chosen for the implementation of the auxiliary
function H. This byte string is used as the value of salt if a (non-null) value is not includedin OtherInput (see below).
If H(x) = HMAC-hash(salt, x), then – in the absence of an agreed-upon alternative – thedefault_salt shall be an all-zero byte string whose bit length equals that specified as the bit
length of an input block for the hash function, hash. (Input-block lengths for the approved
hash functions that can be employed to implement HMAC-hash are listed in Table 1 ofSection 4.2.)
If H(x) = KMAC128(salt, x, H_outputBits, “KDF”), then – in the absence of an agreed-uponalternative – the default_salt shall be an all-zero string of 164 bytes (i.e., an all-zero stringof 1312 bits).

12

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

If H(x) = KMAC256(salt, x, H_outputBits, “KDF”), then – in the absence of an agreed-uponalternative – the default_salt shall be an all-zero string of 132 bytes (i.e., an all-zero stringof 1056 bits).
Input:
1. Z – a byte string that represents the shared secret.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

2. OtherInput, which includes:a. {salt} – A non-null (secret or non-secret) byte string that can be (optionally) provided ifeither Option 2 (HMAC-hash) or Option 3 (KMAC#) is chosen for the implementationof the auxiliary function H since those options require a salt value that is used as a MAC
key.
The salt included in OtherInput could be, for example, a value computed from nonces
exchanged as part of a key-establishment protocol that employs one or more of the keyagreement schemes specified in [SP 800-56A] or [SP 800-56B], a value already sharedby the protocol participants, or a value that is pre-determined by the protocol. The
possibilities for the length of salt are determined as follows:(1) The HMAC-hash algorithm, as defined in [FIPS 198], can accommodate MAC keysof any bit length permitted for input to the hash function, hash. Therefore, when
Option 2 is chosen, the length of the byte string salt can be as large as allowed forany string used as input to hash. However, if the bit length of salt is greater than the
bit length specified for a single input block for the hash function, hash, then the valueof salt is replaced by hash(salt) as part of the HMAC computation. See Table 2 fordetails.
(2) The KMAC128 and KMAC256 algorithms specified in [SP 800-185] canaccommodate MAC keys of any length up to (22040 – 1) bits. Therefore, when Option
3 is chosen, salt can be a byte string of any agreed-upon length that does not exceed(22037 – 1 bytes) (i.e., 22040 – 8 bits). The input salt value will be (re)formatted (using
a byte-padding function) during the execution of the KMAC algorithm to obtain astring whose length is a multiple of either 168 bytes (for KMAC128) or 136 bytes(for KMAC256). See Table 3 for details.
If a salt value required by H is omitted from OtherInput (or if a required salt value
included in OtherInput is the null string), then the value of default_salt shall be used as
the value of salt when H is executed.
b. L – A positive integer that indicates the length (in bits) of the secret keying material to
be derived; L shall not exceed H_outputBits × (232 –1).
(L = keydatalen in the notation of previous versions of [SP 800-56A], while L = KBits inthe notation of previous versions of [SP 800-56B]; current versions of those documents
have been updated to be consistent with SP 800-56C.)
c. FixedInfo – A bit string of context-specific data that is appropriate for the relying keyestablishment scheme. As its name suggests, the value of FixedInfo does not change
during the execution of the process described below.
FixedInfo may, for example, include appropriately formatted representations of the13

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

values of salt and/or L. The inclusion of additional copies of the values of salt and L in
FixedInfo would ensure that each block of derived keying material is affected by all of
the information conveyed in OtherInput. See [SP 800-56A] and [SP 800-56B] for moredetailed recommendations concerning the format and content of FixedInfo (also known
as OtherInfo in earlier versions of those documents).
Process:

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

1.

If L > 0, then set reps = L / H_outputBits; otherwise, output an error indicator and exit
this process without performing the remaining actions (i.e., omit steps 2 through 8).

2.

If reps > (232 −1), then output an error indicator and exit this process without performing
the remaining actions (i.e., omit steps 3 through 8).

3.

Initialize a big-endian 4-byte unsigned integer counter as 0x00000000, corresponding to
a 32-bit binary representation of the number zero.

4.

If counter || Z || FixedInfo is more than max_H_inputBits bits long, then output an error
indicator and exit this process without performing any of the remaining actions (i.e., omit
steps 5 through 8).

5.

Initialize Result(0) as an empty bit string (i.e., the null string).

6.

For i = 1 to reps, do the following:
6.1

Increment counter by 1.

6.2

Compute K(i) = H(counter || Z || FixedInfo).

6.3 Set Result(i) = Result(i – 1) || K(i).
7.

Set DerivedKeyingMaterial equal to the leftmost L bits of Result(reps).

8.

Output DerivedKeyingMaterial.

Output:The bit string DerivedKeyingMaterial of length L bits (or an error indicator).
Notes:In step 6.2 above, if H(x) = hash(x) or H(x) = HMAC-hash(salt, x), the entire output block of
the hash function, hash, shall be used when computing the output of H. Some approved
choices for hash (e.g., SHA-512/224, SHA-512/256, and SHA-384, as specified in [FIPS 180])
include an internal truncation operation. In such a case, the “entire output” of hash is the output
block as defined in its specification. (For example, in the case of hash = SHA-384, the entire
output is defined as a 384-bit block resulting from the internal truncation of a certain 512-bit
value).
If H(x) = KMAC#(salt, x, H_outputBits, S), then choosing H_outputBits = L will likely be themost efficient way to produce the desired L bits of keying material.
The derived keying material DerivedKeyingMaterial shall be computed in its entirety before
outputting any portion of it.
14

NIST SP 800-56C REV. 2

4.2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESThe Auxiliary Function H(x) and Related Parameters

Tables 1, 2, and 3 enumerate the possibilities for the auxiliary function H and provide additional
information concerning the values of related parameters, such as H_outputBits andmax_H_inputBits. The tables also indicate the range of security strengths that can be supported byeach choice for H (see Section 4.1) when used in a key derivation function for a key-establishment
scheme specified in SP 800-56A or SP 800-56B.
Table 1: H(x) = hash(x) (Option 1)
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Hash
Function(hash)

SecurityStrength s
supported(in bits)

Byte / Bit
Length of
Input Blocks

H_outputBits(in bits)

SHA-1

64 / 512160

SHA-224

64 / 512224

SHA-256

64 / 512256

112 ≤ s ≤ 256

SHA-512/224

128 / 1024

224

112 ≤ s ≤ 224

SHA-512/256

128 / 1024

256

SHA-384

128 / 1024

384

SHA-512128 / 1024

512

SHA3-224

144 / 1152

224

SHA3-256

136 / 1088

256

SHA3-384

104 / 832

384

SHA3-512

72 / 576

512

max_H_inputBits(in bits)

112 ≤ s ≤ 160
64

≤2 –1

≤ 2128 – 1

112 ≤ s ≤ 224

112 ≤ s ≤ 256
112 ≤ s ≤ 384
112 ≤ s ≤ 512

Arbitrarily long
inputs can beaccommodated.

112 ≤ s ≤ 224
112 ≤ s ≤ 256
112 ≤ s ≤ 384
112 ≤ s ≤ 512

Table 2: H(x) = HMAC-hash(salt, x) (Option 2)
Effective
Byte / Bit
Length*of salt

H_outputBits(in bits)

SHA-1

64 / 512160

SHA-224

64 / 512224

SHA-256

64 / 512256

112 ≤ s ≤ 256

SHA-512/224

128 / 1024

224

112 ≤ s ≤ 224

SHA-512/256

128 / 1024

256

SHA-384

128 / 1024

384

SHA-512128 / 1024

512

SHA3-224

144 / 1152

224

Hash
Function(hash)

max_H_inputBits(in bits)

SecurityStrength s
supported(in bits)
112 ≤ s ≤ 160

64≤ 2 – 513

≤ 2128 – 1025

112 ≤ s ≤ 224

112 ≤ s ≤ 256
112 ≤ s ≤ 384
112 ≤ s ≤ 512

Arbitrarily long15

112 ≤ s ≤ 224

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESSHA3-256

136 / 1088

256

SHA3-384

104 / 832

384

SHA3-512

72 / 576

512

inputs can beaccommodated.

112 ≤ s ≤ 256
112 ≤ s ≤ 384
112 ≤ s ≤ 512

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2* This Recommendation places no restriction on the length of a chosen salt other than therequirement that its byte length be greater than zero but no greater than the length of a single input
block to the hash function, hash, used to implement HMAC-hash. That freedom of choice issomewhat illusory, however, since the HMAC algorithm will convert an input salt value (asneeded) into a string of the indicated hash-dependent length. A shorter salt (used by H as an
HMAC key) will be padded by appending an all-zero bit string to obtain a string of the indicatedlength (the length of a single input block for the hash function, hash); a longer salt will be hashedto produce a shorter string (of bit length H_outputBits), which will then be padded (by appendingan all-zero bit string) to obtain a string of the indicated length (see [FIPS 198] for additional
information).
Table 3: H(x) = KMAC#(salt, x, H_outputBits, “KDF”) (Option 3)
KMAC
Variant
KMAC128

KMAC256

Lengthof theencodedsalt value

Suggested
Maximum
Byte Lengthof salt

Multipleof 168bytes
Multipleof 136bytes

168 – 4 =164 **
136 – 4 =132 ***

H_outputBits(in bits)

max_H_inputBits(in bits)

Choice of 160,
224, 256, 384,
512, or L.

Arbitrarily long
inputs can beaccommodated.

SecurityStrength s
supported(in bits)
112 ≤ s ≤ 128

112 ≤ s ≤ 256** KMAC# prepends a length encoding for the first input data field. For KMAC128, using 164
bytes (or less) of salt leaves room for 4 bytes of prepended length encoding and limits the lengthof the encoded salt to no more than the length of a single block of input to KMAC128.
*** KMAC# prepends a length encoding for the first input data field. For KMAC256, using 132
bytes (or less) of salt leaves room for 4 bytes of prepended length encoding and limits the lengthof the encoded salt to no more than the length of a single block of input to KMAC256.

16

NIST SP 800-56C REV. 2

5

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Two-Step Key Derivation

This section specifies an approved (two-step) extraction-then-expansion key-derivation
procedure. Like the one-step key-derivation functions described in Section 4, the input to this twostep procedure includes the shared secret Z; L, a positive integer indicating the desired length (inbits) of the output keying material; and other information (as determined by the particular
implementation of the key-establishment scheme and/or key-derivation method). In contrast to the
one-step methods, a salt value is required to be included as part of the input.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

The extraction-then-expansion key-derivation procedure is pictured in Figure 1.
L, {IV,} FixedInfo

Z

salt

Randomness
Extraction

KDK

Key
Expansion

DerivedKeyingMaterial

Figure 1: The Extraction-then-Expansion Key-Derivation Procedure

The first (randomness-extraction) step uses either HMAC (as defined in [FIPS 198]) or AESCMAC (as defined in [SP 800-38B]). In either case, there are two inputs: salt, which serves as a
MAC key and the shared secret, Z, which serves as the “message.” The resulting MAC output isused as a key-derivation key, KDK. The use of the KDK shall be restricted to the execution of the
key-expansion step of the (two step) key-derivation procedure in which the KDK is extracted fromZ. In particular, its value shall not be an output of the extraction-then-expansion key-derivation
procedure.
The second (key-expansion) step uses the key-derivation key, KDK, along with the integer L andother appropriate data as the input to a PRF-based key-derivation function specified in [SP 800108]. The output returned by that key-derivation function is either secret keying material (in theform of DerivedKeyingMaterial, a bit string of length L) or an error indicator.
5.1

Specification of Key-Derivation Procedure

The extraction-then-expansion key-derivation procedure is specified as follows:
Function call: KDM( Z, OtherInput).
Options for the Auxiliary MAC Algorithm:
The MAC algorithm employed for randomness extraction shall be either an implementation of
HMAC as defined in [FIPS 198], based on an approved hash function, hash (i.e., HMAChash), or an implementation of AES-CMAC as defined in [SP 800-38B] (i.e., AES-N-CMAC
for N = 128, 192, or 256). In either case, the (untruncated) output of the MAC algorithm isused as the key-derivation key for subsequent key expansion. Tables 4 and 5 in Section 5.2
17

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

describe the possibilities for the auxiliary MAC algorithm, which shall be chosen inaccordance with the selection requirements specified in Section 7.
Implementation-Dependent Auxiliary PRF-based KDF:
One of the general-purpose, PRF-based key-derivation functions defined in [SP 800-108] shallbe used for key expansion. These key-derivation functions employ an approved MAC
algorithm as the PRF. In this Recommendation, the PRF used by the KDF in key expansion isdetermined by the MAC algorithm that is used for randomness extraction. Specifically:
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

a. If HMAC-hash is used in the randomness-extraction step, then the same HMAC-hash (i.e.,
using the same hash function, hash) shall be used as the PRF in the key-expansion step;andb. If AES-128-CMAC, AES-192-CMAC, or AES-256-CMAC is used in the randomnessextraction step, then only AES-128-CMAC (i.e., the CMAC mode of AES-128) shall be
used as the PRF in the key-expansion step.
The rationale for these rules is discussed in Section 8.3.
Input:
1. Z – A byte string that represents the shared secret. It is used as the “message” during theexecution of the MAC algorithm employed in the randomness-extraction step.
2. OtherInput, which includes:a. salt – A non-null (secret or non-secret) byte string used as the MAC key during theexecution of the randomness-extraction step (i.e., step 1 in the process shown below). Thissalt could be, for example, a value computed from nonces exchanged as part of a keyestablishment protocol that employs one or more of the key-agreement schemes specified
in [SP 800-56A] or [SP 800-56B], a value already shared by the protocol participants, or avalue that is pre-determined by the protocol. The possibilities for the length of salt are
determined by the auxiliary MAC algorithm that is used for randomness extraction:(1) The HMAC-hash algorithm as defined in [FIPS 198] can accommodate keys of any
length up to the maximum bit length permitted for input to the hash function, hash.
Therefore, the length of the byte string salt can be as large as allowed for any stringused as input to hash. However, if the bit length of salt is greater than the bit length
specified for a single input block for hash, then the value of salt is replaced byhash(salt) as part of the HMAC computation. (Input-block lengths for the approved
hash functions that can be employed to implement HMAC-hash are included in column
4 of Table 1 in Section 4.2; also see Table 4 of Section 5.2.) In the absence of an agreedupon alternative, the input salt value shall be an all-zero byte string whose length isequal to that of a single input block for the hash function, hash.
(2) AES-N-CMAC requires keys that are N bits long (for N = 128, 192, or 256), depending
upon the AES variant that is used in the implementation. The bit length of salt shall be

18

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

the bit length required of a key for that AES variant (128 bits for AES-128, 192 bits for
AES-192, or 256 bits for AES-256). In the absence of an agreed-upon alternative, theinput salt value shall be an all-zero string of the required bit length.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

b. L – A positive integer that indicates the length (in bits) of the secret keying material to be
derived using the auxiliary PRF-based KDF during the execution of the key-expansion step(i.e., step 2 in the process shown below). The maximum value allowed for L is determinedby the mode (i.e., Counter Mode, Feedback Mode, or Double-Pipeline Iteration Mode) and
implementation details of the chosen KDF (as specified in [SP 800-108]). An error event
will occur during the execution of the KDF if L is too large. 13(Note that L = keydatalen in the notation of previous versions of [SP 800-56A], while L =KBits in the notation of previous versions of [SP 800-56B]; current versions of those
documents have been updated to be consistent with SP 800-56C.)
c. {IV} – A bit string included (if required) for use as an initial value during an execution of
the auxiliary PRF-based KDF; an IV shall be included in OtherInput if and only if thechosen PRF-based KDF is operating in Feedback Mode. It can either be secret or nonsecret. It may be an empty string. If the PRF-based KDF is operating in either Counter
Mode or Double-Pipeline Iteration Mode, an IV shall not be included in OtherInput. (See[SP 800-108] for details.)
d. FixedInfo, including:(1) Label – A bit string that identifies the purpose for the derived keying material. For
example, it can be the ASCII encoding of a character string describing the relying
application(s) and/or the intended use(s) of the keying material. The value and encoding
method used for the Label are defined in a larger context, for example, in the protocolthat uses this key-derivation procedure. As an alternative to including this string as aseparate component of FixedInfo, Label could be incorporated in Context (see below).
(2) Context – A bit string of context-specific data appropriate for the relying keyestablishment scheme/protocol and the chosen PRF-based KDF.
For recommendations concerning the format and context-specific content of Context,
see the specifications of FixedInfo and/or OtherInfo in [SP 800-56A] and/or [SP 80056B], respectively.
(3) [L]2 – An agreed-upon encoding of L as a bit string that is appropriate for use by the chosen
PRF-based KDF (see [SP 800-108] for details). As an alternative to including this string
as a separate component of FixedInfo, [L]2 could be incorporated in Context (seeabove).

13

The restrictions on the size of L that are given in [SP 800-108] are stated in terms of n = L/h, where h denotes the bit length ofan output block of the PRF used to implement the auxiliary KDF. In the case of Counter Mode, the restriction is n ≤ 2r – 1, wherer ≤ 32 is the (implementation-dependent) bit length allocated for the KDF’s counter variable. For the other KDF modes, therestriction is simply n ≤ 232 – 1.

19

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Process:[Randomness Extraction]
1. Call MAC( salt, Z, …) to obtain KDK or an error indicator. If an error occurs, output an error
indicator, and exit from this process without performing step 2.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2[Key Expansion]
2. Call KDF( KDK, L, {IV,} FixedInfo ) to obtain DerivedKeyingMaterial or an error indicator(see [SP 800-108] for details). If an error occurs, output an error indicator; otherwise output
DerivedKeyingMaterial.
Output:The bit string DerivedKeyingMaterial of length L bits (or an error indicator).
Notes:
When HMAC-hash is used as the auxiliary MAC algorithm, the length of KDK is the length ofan untruncated output block from the hash function, hash. When AES-CMAC is used, then(regardless of the AES variant employed) KDK is a 128-bit binary string. KDK is used (locally)
as a key-derivation key by the auxiliary KDF during the key-expansion step and shall be
destroyed (along with all other sensitive, locally stored data) after its use. Its value shall not
be an output of the key-derivation procedure.
[RFC 5869] specifies a version of the above extraction-then-expansion key-derivation procedureusing HMAC for both the extraction and expansion steps. For an extensive discussion concerning
the rationale for the extract-and-expand mechanisms specified in this Recommendation, see[LNCS 6223].
5.2

The Auxiliary MAC Algorithm and Related Parameters

Tables 4 and 5 enumerate the possibilities for the auxiliary MAC algorithm used for randomness
extraction and provide additional information concerning the lengths of the MAC key (i.e., the salt
value) and the extracted key-derivation key (i.e., KDK). The tables also indicate the range of
security strengths that can be supported by each choice for MAC (see Section 5.1) when used fortwo-step key derivation in a key-establishment scheme specified in SP 800-56A and SP 800-56B.
Table 4: MAC( salt, Z, …) = HMAC-hash( salt, Z ) (For Randomness Extraction)
Hash
Function(hash)

Effective
Byte / Bit
Length*of salt

Bit Length ofExtracted KDK

SecurityStrength s
supported(in bits)

SHA-1

64 / 512160

112 ≤ s ≤ 160

SHA-224

64 / 512224

112 ≤ s ≤ 224

SHA-256

64 / 512256

112 ≤ s ≤ 256

20

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

SHA-512/224

128 / 1024

224

112 ≤ s ≤ 224

SHA-512/256

128 / 1024256

112 ≤ s ≤ 256

SHA-384

128 / 1024

384

112 ≤ s ≤ 384

SHA-512128 / 1024512

112 ≤ s ≤ 512

SHA3-224

144 / 1152

224

112 ≤ s ≤ 224

SHA3-256

136 / 1088

256

112 ≤ s ≤ 256

SHA3-384

104 / 832

384

112 ≤ s ≤ 384

SHA3-512

72 / 576512

112 ≤ s ≤ 512* This Recommendation places no restriction on the length of a chosen salt other than therequirement that its byte length be greater than zero but no greater than the length of a single input
block to the hash function, hash, used to implement HMAC-hash. That freedom of choice issomewhat illusory, however, since the HMAC algorithm will convert an input salt value (asneeded) into a string of the indicated hash-dependent length. A shorter salt (which is used as an
HMAC key) will be padded (by appending an all-zero bit string) to obtain a string of the indicatedlength (the length of a single input block for the hash function, hash); a longer salt will be hashedto produce a shorter string, which will then be padded (by appending an all-zero bit string) toobtain a string of the indicated length. (See [FIPS 198] for additional information.)
Note: The hash function, hash, used by the HMAC algorithm employed during randomness
extraction shall be used again in the subsequent key-expansion step to implement the HMAC
algorithm that is employed as a PRF by the auxiliary PRF-based KDF.
Table 5: MAC( salt, Z, …) = AES-N-CMAC( salt, Z ) (For Randomness Extraction)
AES Variant
used by
AES-CMAC

Bit Lengthof salt for
AES-CMAC

AES-128

128

AES-192

192

AES-256

256

Bit Length ofExtracted KDK

128

SecurityStrength s
supported(in bits)
112 ≤ s ≤ 128

Note: Regardless of which AES variant is used by the AES-CMAC algorithm during randomnessextraction, the 128-bit AES block size determines the bit length of the resulting KDK and the
maximum security strength that can be supported by the use of the derived keying material (i.e.,
no more than 128 bits). To accommodate the use of this 128-bit KDK as a key-derivation key, the
CMAC mode of AES-128 shall be the PRF employed by the auxiliary PRF-based KDF in thesubsequent key-expansion step.
5.3

Randomness Extraction followed by Multiple Key Expansions

The two-step key-derivation procedure specified in Section 5.1 can be generalized to incorporate
21

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

a single instance of randomness extraction followed by m instances of key expansion for some
(implementation-dependent) integer m ≥ 2.
L1, {IV1,} FixedInfo1
Key
Expansion
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Z

salt

Randomness
Extraction

KDK

L2, {IV2,} FixedInfo2

KDK

KDK

DerivedKeyingMaterial1

Key
Expansion

DerivedKeyingMaterial2•••

Lm, {IVm,} FixedInfomKey
Expansion

DerivedKeyingMaterialm

Figure 2: Randomness Extraction followed by Multiple Key Expansions

For conformance with this Recommendation, the following restrictions apply:•

The auxiliary MAC algorithm employed for randomness extraction shall be either animplementation of HMAC as defined in [FIPS 198], based on an approved hash function, hash(i.e., HMAC-hash), or an implementation of AES-CMAC as defined in [SP 800-38B] (i.e.,
AES-N-CMAC for N = 128, 192, or 256). In either case, the (untruncated) output of the MAC
algorithm shall be used as the key-derivation key for subsequent key expansion. Tables 4 and5 in Section 5.2 describe the possibilities for the auxiliary MAC algorithm, which shall bechosen in accordance with the selection requirements specified in Section 7.

•

One of the general-purpose, PRF-based key-derivation functions defined in [SP 800-108] shall be
used for key expansion. The same KDF shall be used to implement all m expansion operations.
In particular, the same key-derivation mode (counter mode, feedback mode, or double-pipeline
iteration mode) and the same PRF shall be employed by the KDF in each of the m keyexpansion operations.

•

The PRF used by the KDF in key expansion is determined by the MAC algorithm that is used
for randomness extraction. Specifically:a. If HMAC-hash is used for randomness extraction, then the same HMAC-hash (i.e., using
22

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

the same hash function, hash) shall be the PRF used by the KDF in key expansion.
andb. If either AES-128-CMAC, AES-192-CMAC, or AES-256-CMAC is used for randomness
extraction, then the PRF used by the KDF in key-expansion shall be AES-128-CMAC(i.e., the CMAC mode of AES-128).
•

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

The OtherInput provided during the key-derivation request shall provide the salt for the
randomness-extraction step (see Section 5.1 for additional details), and the requisite inputs(other than the key-derivation key) for m calls to the PRF-based KDF used for key expansion.
In particular, for i = 1, .., m, OtherInput shall include (subject to the stated conditions):
a. Li – A positive integer that indicates the length (in bits) of the secret keying material to be
derived during the i-th call to the PRF-based KDF. (See the description of L in Section
5.1 for additional details.)b. {IVi} – A bit string included (if required) for use as an initial value for the i-th call to the
PRF-based KDF; the IVi values shall be included in OtherInput if and only if the chosen
PRF-based KDF is operating in Feedback Mode. (See the description of IV in Section 5.1
for additional details.)c. FixedInfoi – The FixedInfo data to be employed during the i-th call to the PRF-based KDF.
(See the description of FixedInfo in Section 5.1 for details.)•

The values of FixedInfo1 , FixedInfo2 , … , and FixedInfom shall be (pairwise) distinct. (See
Section 7.5, item 2 in [SP 800-108].)•

The derived keying material, DerivedKeyingMaterial1, DerivedKeyingMaterial2, … , andDerivedKeyingMaterialm shall not be output until all m of the bit strings have beensuccessfully computed. If an error occurs during randomness extraction or key expansion, thenthis key-derivation method shall not output any derived keying material.

To incorporate m key-expansion operations into an extract-then-expand key-derivation procedure,
the process and output specified in Section 5.1 are modified as follows:
Process:[Randomness Extraction]
1. Call MAC( salt, Z, …) to obtain KDK or an error indicator; if an error occurs, output anerror indicator and exit from this process without performing steps 2 and 3.
[Key Expansion]
2. For i = 1 to m, do the following:
2.1

Call KDF( KDK, Li, {IVi,} FixedInfoi) to obtain DerivedKeyingMateriali or an error
indicator (see [SP 800-108] for details). If an error occurs, output an error
indicator and exit this process without performing any of the remaining actions (inparticular, omit step 3).

3. For i = 1 to m, do the following:

23

NIST SP 800-56C REV. 2

3.1

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Output DerivedKeyingMateriali .

Output:The bit strings DerivedKeyingMaterial1, DerivedKeyingMaterial2, … , andDerivedKeyingMaterialm of lengths L1 bits, L2 bits, … , and Lm bits, respectively(or an error indicator).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Notes:As specified in Section 5.1: When HMAC-hash is used as the auxiliary MAC algorithm, thelength of KDK is the length of an untruncated output block from the hash function, hash. When
AES-CMAC is used, then (regardless of the AES variant employed) KDK is a 128-bit binary
string. The extracted KDK is used (locally) as a key-derivation key by the auxiliary KDF during
key expansion (step 2 above) and shall be destroyed (along with all other sensitive locallystored data) after its use. Its value shall not be an output of the key-derivation procedure.

24

NIST SP 800-56C REV. 2

6

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESApplication-Specific Key-Derivation Methods

Additional approved, application-specific key-derivation methods are enumerated in[SP 800-135]. Unless an explicit exception is made in [SP 800-135], any hash function or MAC
algorithm employed by the key-derivation methods enumerated in [SP 800-135] shall beapproved and shall also meet the selection requirements specified in this Recommendation (i.e.,
SP 800-56C).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

25

NIST SP 800-56C REV. 2

7

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Selecting Hash Functions and MAC Algorithms

The key-derivation methods specified in this Recommendation, as well as those enumerated in [SP800-135], use hash functions and/or message authentication code (MAC) algorithms as auxiliary
functions. In particular:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2•

The one-step key-derivation functions that are specified in Section 4.1 of thisRecommendation employ an appropriate choice of hash function (hash), an HMAC
algorithm based on an appropriate choice of hash function (HMAC-hash), or one of two
KMAC variants (KMAC128 or KMAC256) to implement the auxiliary function H.

•

The extraction-then-expansion key-derivation procedure specified in Section 5.1 employs
either an HMAC algorithm based on an appropriate choice of hash function (HMAC-hash)for both randomness extraction and key expansion or an appropriate variant of the AESCMAC algorithm (i.e., AES-N-CMAC for N = 128, 192, or 256) for randomness extraction
together with AES-128-CMAC for key expansion.

Unless explicitly stated to the contrary (e.g., in [SP 800-135]), the following requirements apply tothe hash functions and MAC algorithms employed for key derivation:•

Whenever a hash function is employed (including as the primitive used by HMAC), an
approved hash function shall be used. [FIPS 180] and [FIPS 202] specify approved hashfunctions.

•

Whenever an HMAC algorithm is employed, the HMAC implementation shall conform to
the specifications found in [FIPS 198].

•

Whenever a KMAC variant (KMAC128 or KMAC256) is employed, the KMAC
implementation shall conform to the specifications found in [SP 800-185].

•

Whenever an AES-CMAC algorithm is employed, the implementation of AES shallconform to [FIPS 197], and the AES-CMAC implementation shall conform to [SP 80038B].

As specified in [SP 800-56A] and [SP 800-56B], an approved key-establishment scheme can be
implemented with parameters of various types and sizes that will impact the estimated maximum
security strength that can be supported by the resulting scheme. When a key-establishment scheme
employs a choice of parameters that are associated with a targeted security strength of s bits, theselection of a hash function, HMAC, KMAC, or AES-CMAC employed during the implementationof its key-derivation method shall conform to the following restrictions:•

An approved hash function shall be employed (whether alone or as the primitive used by
HMAC) in the implementation of a one-step or two-step key-derivation method only if its
output block length (in bits) is greater than or equal to s.

•

For the purposes of implementing one-step key derivation only: KMAC128 shall be
employed only in instances where s is 128 bits or less. KMAC256 shall be employed only
in instances where s is 256 bits or less. (However, see the note below.)26

NIST SP 800-56C REV. 2•

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESFor the purposes of implementing two-step key derivation only: AES-CMAC shall be
employed only in instances where s is 128 bits or less. (See the note following Table 5.)

Tables 1 through 5 (in Sections 4.1 and 5.1) can be consulted to determine which hash functions
and/or MAC algorithms are approved for use when a key-derivation method specified in thisRecommendation is used by an approved key-establishment scheme to support a targeted security
strength of s bits.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

Note: At the time of publication of this Recommendation, a key-establishment scheme
implemented in accordance with either [SP 800-56A] or [SP 800-56B] can have a targeted security
strength of 256 bits at most.

27

NIST SP 800-56C REV. 2

8

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

Further Discussion

In this section, the following issues are discussed:
8.1

Using a Truncated Hash Function

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

SHA-224, SHA-512/224, SHA-512/256, and SHA-384 are among the approved hash functions
specified in [FIPS 180]. SHA-224 is a truncated version of SHA-256, while SHA-512/224, SHA512/256, and SHA-384 are truncated versions of SHA-512. (Each of these truncated versions uses
a specific initial chaining value, which is different from the initial chaining value used by theuntruncated version.) In applications that require a relatively long bit string of derived keying
material, implementing the key-derivation methods specified in this Recommendation with atruncated version of a hash function may be less efficient than using the corresponding untruncatedversion (i.e., SHA-256 or SHA-512).
8.2

The Choice of a Salt ValueIn this Recommendation, the MAC algorithms employed either in a one-step key-derivation
method or in the randomness-extraction step of a two-step key-derivation method use a salt value
as a MAC key (see Sections 4 and 5). This Recommendation does not require the use of a randomly
selected salt value. In particular, if there are no means to select a salt value and share it with all of
the participants during a key-establishment transaction, then this Recommendation specifies thata predetermined default (e.g., all-zero) byte string be used as the salt value. The benefits of using“random” salt values when possible are discussed (briefly) in Section 3.1 (“To salt or not to salt”)
of [RFC 5869] and in greater detail in [LNCS 6223].
8.3

MAC Algorithms used for Extraction and Expansion

Provided that the targeted security strength can be supported (see Tables 4 and 5 in Section 5.2),
this Recommendation permits either HMAC-hash (i.e., HMAC implemented with an appropriately
chosen approved hash function, hash) or AES-CMAC (i.e., the CMAC mode of AES-128, AES192, or AES-256) to be selected as the MAC algorithm used in the randomness-extraction step of
the key-derivation procedure specified in Section 5.1.
The PRF-based KDF used in the key-expansion step of the procedure also requires an appropriate
MAC (to serve as the PRF). While it may be technically feasible (in some cases) to employ
completely different MAC algorithms in the two steps of the specified key-derivation procedure,
this Recommendation does not permit such flexibility. Instead, the following restrictions have beenplaced on MAC selection (see Sections 5 and 7):•

When HMAC-hash is chosen for use in the randomness-extraction step, the same MAC
algorithm (i.e., HMAC-hash with the same approved hash function, hash) shall be
employed to implement the PRF-based KDF used in the key-expansion step.

•

When AES-128-CMAC, AES-192-CMAC, or AES-256-CMAC is chosen for use in the
randomness-extraction step, the MAC algorithm employed by the PRF-based KDF used in
the key-expansion step shall be AES-128-CMAC, the CMAC mode of AES-128. (AES-28

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

128 is the only AES variant that can employ the 128-bit KDK produced by AES-N-CMAC
during the randomness-extraction step.)•

The MAC algorithm selected for the implementation of a two-step key-derivation method
shall be capable of supporting the targeted security strength as determined by consulting
Tables 4 and 5 in Section 5.2. (This limits the use of AES-CMAC to cases where thetargeted security strength is no more than 128 bits.)

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

The imposed restrictions are intended to reduce the overall complexity of the resulting
implementations, promote interoperability, and simplify the negotiation of the parameters andauxiliary functions affecting the security strength supported by the key-derivation procedure.
Note: At this time, KMAC has not been specified for use in the implementation of a two-step keyderivation procedure. This restriction may be reconsidered once a KMAC-based KDF has been
approved for use as a PRF-based KDF in a revision of [SP 800-108].
8.4

Destruction of Sensitive Locally Stored Data

Good security practice dictates that implementations of key-derivation methods include steps that
destroy potentially sensitive locally stored data that is created (and/or copied for use) during theexecution of a particular process; there is no need to retain such data after the process has been
completed. Examples of potentially sensitive locally stored data include local copies of sharedsecrets that are employed during the execution of a particular process, intermediate results
produced during computations, and locally stored duplicates of values that are ultimately output
by the process. The destruction of such locally stored data ideally occurs prior to or during any
exit from the process. This is intended to limit opportunities for unauthorized access to sensitive
information that might compromise a key-establishment transaction.
It is not possible to anticipate the forms of all possible implementations of the key-derivation
methods specified in this Recommendation, making it equally impossible to enumerate all
potentially sensitive data that might be locally stored by a process employed in a particular
implementation. Nevertheless, the destruction of any potentially sensitive locally stored data is an
obligation of all implementations.

29

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMES

References

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2[FIPS 180]

National Institute of Standards and Technology (2015) Secure Hash Standard(SHS). (U.S. Department of Commerce, Washington, DC), Federal Information
Processing Standards Publication (FIPS) 180-4.
https://doi.org/10.6028/NIST.FIPS.180-4[FIPS 197]

National Institute of Standards and Technology (2001) Advanced Encryption
Standard (AES). (U.S. Department of Commerce, Washington, DC), Federal
Information Processing Standards Publication (FIPS) 197.
https://doi.org/10.6028/NIST.FIPS.197[FIPS 198]

National Institute of Standards and Technology (2008) The Keyed-Hash
Message Authentication Code (HMAC). (U.S. Department of Commerce,
Washington, DC), Federal Information Processing Standards Publication(FIPS) 198-1.
https://doi.org/10.6028/NIST.FIPS.198-1[FIPS 202]

National Institute of Standards and Technology (2015) SHA-3 Standard:
Permutation-Based Hash and Extendable-Output Functions. (U.S. Departmentof Commerce, Washington, DC), Federal Information Processing Standards
Publication (FIPS) 202.
https://doi.org/10.6028/NIST.FIPS.202[LNCS 6223]

Krawczyk H (2010) Cryptographic Extraction and Key Derivation: The HKDF
Scheme. Advances in Cryptology – Crypto’2010, ed. Rabin T (Springer, Berlin,
Germany), Lecture Notes in Computer Science vol. 6223, pp 631-648.
https://doi.org/10.1007/978-3-642-14623-7_34[RFC 5869]

Krawczyk H, Eronen P (2010) HMAC-based Extract-and-Expand Key Derivation
Function (HKDF). (Internet Engineering Task Force (IETF)), IETF Request forComments (RFC) 5869.
https://doi.org/10.17487/RFC5869[SP 800-38B]

Dworkin MJ (2005) Recommendation for Block Cipher Modes of Operation:
the CMAC Mode for Authentication. (National Institute of Standards andTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-38B,
Includes updates as of October 6, 2016.
https://doi.org/10.6028/NIST.SP.800-38B[SP 800-56A]

Barker EB, Chen L, Roginsky A, Davis R (2018) Recommendation for PairWise Key-Establishment Schemes Using Discrete Logarithm Cryptography.
((National Institute of Standards and Technology, Gaithersburg, MD), NIST
Special Publication (SP) 800-56A, Rev. 3.
https://doi.org/10.6028/NIST.SP.800-56Ar3

30

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2[SP 800-56B]

Barker EB, Chen L, Roginsky A, Vassilev A, Davis R, Simon S (2019)
Recommendation for Pair-Wise Key-Establishment Using Integer
Factorization Cryptography. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-56B, Rev. 2.
https://doi.org/10.6028/NIST.SP.800-56Br2[SP 800-57]

Barker EB (2020) Recommendation for Key Management, Part 1: General.
(National Institute of Standards and Technology, Gaithersburg, MD), Draft
NIST Special Publication (SP) 800-57 Part 1, Rev. 5.
https://doi.org/10.6028/NIST.SP.800-57pt1r5[SP 800-108]

Chen L (2009) Recommendation for Key Derivation Using Pseudorandom
Functions (Revised). (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-108, Revised.
https://doi.org/10.6028/NIST.SP.800-108[SP 800-131A]

Barker EB, Roginsky A (2019) Transitioning the Use of Cryptographic
Algorithms and Key Lengths. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-131A, Rev. 2.
https://doi.org/10.6028/NIST.SP.800-131Ar2[SP 800-135]

Dang QH (2011) Recommendation for Existing Application-Specific Key
Derivation Functions. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-135, Rev. 1.
https://doi.org/10.6028/NIST.SP.800-135r1[SP 800-185]

Kelsey JM, Chang S-jH, Perlner RA (2016) SHA-3 Derived Functions: cSHAKE,
KMAC, TupleHash, and ParallelHash. (National Institute of Standards andTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-185.
https://doi.org/10.6028/NIST.SP.800-185

31

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESAppendix A: Revisions (Informative)
A.1

The Original Version of SP 800-56C

The original SP 800-56C (published in November 2011) focused entirely on the specification of a
two-step extraction-then-expansion key-derivation procedure to be used in conjunction with a keyestablishment scheme from either [SP 800-56A] or [SP 800-56B]. It provided an alternative to the
one-step key-derivation functions that were already included in those companion publications.
A.2

Revision 1

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2

The 2018 revision of SP 800-56C reorganized the original content (it still included thespecification of an extraction-then-expansion key-derivation procedure) to also include thespecification of a family of one-step key-derivation functions, expanding on material that waspreviously found only in SP 800-56A and SP 800-56B. This change was made in support of theremoval of detailed descriptions of key-derivation methods from SP 800-56A and a future revisionof SP 800-56B. The consolidation of specifications in SP 800-56C, Revision 1 promoted
consistency between the key-derivation options available for use with an approved keyestablishment scheme chosen from either of those companion NIST publications. (A number ofapplication-specific key-derivation methods specified in [SP 800-135] continued to be supported.)Specifically named key-establishment “parameter sets” (FA – FC for finite-field cryptography(FFC); EA – EE for elliptic-curve cryptography (ECC); and IA – IB for integer-factorization
cryptography (IFC)) were no longer used as guides for choosing the auxiliary functions employed
by a key-derivation method. Instead, SP 800-56C, Revision 1 indicated the security strengths that
could be supported by the various possibilities for the auxiliary functions. Implementers were
expected to let the targeted security strength of the key-establishment scheme guide their choices.
Of course, each of the named parameter sets was associated with a targeted security strength, so
this was more a change of perspective rather than of substance. The change was, however,consistent with the revision of [SP 800-56A], which de-emphasized (in the FFC case) or eliminated(in the ECC case) the use of named parameter (size) sets.
There was one substantial change to the specification of key-derivation methods that is worth
noting: a KMAC-based option for implementing the auxiliary function H was added to thespecification of one-step key-derivation functions (see Section 4.1). At that time, however, KMAC
had not been specified for use as an auxiliary MAC algorithm in the two-step extraction-thenexpansion key-derivation procedure (see Section 8.3).
Given the extent to which SP 800-56C had been revised, it is impractical to list all of the changes
that were made to the original text. It is recommended that SP 800-56C, Revision 1 be read in its
entirety in order to gain familiarity with the details of the current specifications for both the onestep and two-step key-derivation methods used in approved key-establishment schemes.
A.3

Revision 2

The 2020 revision of SP 800-56C involves just a few changes to the 2018 version of the document.

32

NIST SP 800-56C REV. 2

RECOMMENDATION FOR KEY DERIVATION METHODSIN KEY ESTABLISHMENT SCHEMESIn Section 2, the applicability of the various key-derivation methods specified in thisRecommendation is expanded to permit the use of “hybrid” shared secrets of the form Z′ = Z || T,
which is a concatenation consisting of a “standard” shared secret Z that was generated during theexecution of a key-establishment scheme as currently specified in [SP 800-56A] or [SP 800-56B],
followed by an auxiliary shared secret T that has been generated using some other method.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Cr2This is not a substantive change in the case of one-step key-derivation methods, which derive
blocks of keying material from input of the form counter || Z || FixedInfo. Implementations ofapproved key-establishment schemes have considerable latitude concerning the content andformat of the context-specific data included in FixedInfo. Replacing Z with Z′ = Z || T is equivalent
to replacing FixedInfo with FixedInfo′ = T || FixedInfo, which was already permitted. As inprevious versions of this document, T could instead be used as a salt value by the auxiliary function
H (see Option 2 and Option 3) and/or included in some (other) subfield of FixedInfo. (See Section
4.1 and Section 4.2 for details.)
In the case of the two-step key-derivation methods, the extraction of a key-derivation key from ashared secret of the form Z || T is a bona fide extension of the previously specified technique but isstill consistent with the principles of randomness extraction and key expansion as presented in[LNCS 6223]. Prior to this revision, T could only have been included either as a salt value (in an
HMAC-based extraction step) or as part of the FixedInfo used in the key-expansion step. (See
Section 5.1 and Section 5.2 for details.)
The other change made in the 2020 revision affects the key-expansion step of the approved twostep key-derivation methods. The newly added Section 5.3 specifies the conditions under which
multiple instances of key expansion can be performed using a single key-derivation key obtained
via randomness extraction.
A specific change: In Section 3.1, the definition for hash function was modified to include all threeproperties often required of a cryptographic hash function and to state that the pre-image resistanceof a hash function is a contributing factor when determining the security strength provided by a
key-derivation method.

33