← Back to Blog Standards

NIST SP 800-56C: Key Derivation Through Extract-Expand

8 min read
NIST SP 800-56C: Key Derivation Through Extract-Expand - QNSQY post-quantum encryption guide

After two parties run a key-establishment scheme such as ECDH or ML-KEM, they share a secret. That shared secret is not used directly as a symmetric key. It goes through a key-derivation method that turns it into keys of the right length, tied to their context. NIST SP 800-56C Revision 2, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes", published in August 2020, specifies the methods NIST approves. This walkthrough covers its two families, the hash and MAC choices, and how QNSQY's own key derivation compares.

What SP 800-56C Contains

The document has two main parts:

  • One-step key derivation (Section 4): a key-derivation function applied directly to the shared secret Z and other input.
  • Two-step key derivation (Section 5): randomness extraction from Z, followed by key expansion. Section 5.3 covers one extraction followed by several expansions, for deriving several keys.

It also covers application-specific methods (Section 6), selecting hash functions and MAC algorithms (Section 7), and further discussion of truncated hashes, salt values, the MAC algorithms used for extraction and expansion, and destroying sensitive data (Section 8).

One-Step Key Derivation

The one-step method computes the output by iterating an auxiliary function H over a 32-bit counter, the shared secret Z and FixedInfo, until enough bits are produced. SP 800-56C offers three options for H:

  1. A hash function, H(x) = hash(x).
  2. HMAC, H(x) = HMAC-hash(salt, x).
  3. KMAC, H(x) = KMAC128 or KMAC256 (salt, x, output length, "KDF").

Two-Step Key Derivation

The two-step method first applies a MAC with a salt to Z to extract a key-derivation key, then uses that key with a key-derivation function from SP 800-108 to expand it into the required keying material. The extraction MAC is either HMAC or AES-CMAC.

SP 800-56C notes that RFC 5869 specifies a version of this extraction-then-expansion procedure that uses HMAC for both steps, which is better known as HKDF.

Hash Functions and Security Strength

Tables 1 and 2 of SP 800-56C list the hash functions allowed for the one-step options and for HMAC: SHA-1, the SHA-2 family (SHA-224, SHA-256, SHA-512/224, SHA-512/256, SHA-384, SHA-512) and the SHA-3 family (SHA3-224 to SHA3-512). The security strength a function supports runs from 112 bits up to its output length in bits:

  • SHA-256, HMAC-SHA-256 and SHA3-256 support security strengths from 112 to 256 bits.
  • SHA-384 supports up to 384 bits, and SHA-512 up to 512 bits.
  • SHA-1 supports 112 to 160 bits. The SP 800-131A Rev. 3 draft proposes retiring SHA-1 after 2030, so new designs should avoid it. See SP 800-131A.

In other words, HMAC-SHA-256 can derive a key for a 256-bit security strength. Choosing a hash with a longer output does not by itself make a key stronger.

FixedInfo: Binding the Context

The other input to the derivation includes FixedInfo, the context information that the key-establishment scheme specifies. SP 800-56A Rev. 3 gives recommended formats: an AlgorithmID that says how the derived keying material will be used, PartyUInfo and PartyVInfo that identify the two parties, and optional supplementary public and private information. When several keys are derived from one extraction, SP 800-56C requires the FixedInfo values for the expansions to be distinct. Binding the context this way stops the same shared secret from producing the same key in two different uses.

Salt

In the two-step method the salt is the key for the extraction MAC. SP 800-56C discusses the choice of a salt value in Section 8.2. A salt does not need to be secret, and a fresh random salt per session means that even a repeated shared secret would not produce the same keys.

Common Implementation Mistakes

  • Using the shared secret directly as a key, without any key derivation.
  • Deriving several keys without distinct context information, which removes domain separation between them.
  • Mismatched parameters between implementations: a different salt, hash function or FixedInfo encoding produces different keys. Known-answer tests catch this early.
  • Leaving intermediate values in memory: SP 800-56C requires sensitive locally stored data, such as the extracted key-derivation key, to be destroyed after use.

How QNSQY Derives File Keys

QNSQY's key derivation for a hybrid file works like this, as described in its published .qs file format specification:

  1. ML-KEM and X25519 each produce a 32-byte shared secret.
  2. The two secrets are combined with BLAKE3 in key-derivation mode, using length-prefixed inputs and a version label.
  3. HKDF-SHA3-256 derives the file keys and the per-chunk nonces from the result and a fresh 32-byte random salt stored in the file header, with a separate context label for each key. Files that use the optional SHA-512 hash profile use HKDF-SHA-512 instead.
  4. The data is encrypted in chunks with AES-256-GCM or XChaCha20-Poly1305 under the per-file data key.

Each file header also carries a 32-byte key commitment and a header MAC, which let a reader detect a wrong key or a tampered header before decrypting, and every chunk has its own AEAD tag.

HKDF with SHA3-256 is an HMAC-based extraction-then-expansion procedure of the kind SP 800-56C describes. The step before it is not: BLAKE3 is not an approved function under SP 800-56C, so QNSQY's key derivation as a whole is not an SP 800-56C method. QNSQY is not FIPS 140-3 validated, and its approved-mode build, not yet released, uses ML-KEM on its own with approved functions only.

Frequently Asked Questions

Is HKDF the same as the SP 800-56C two-step method?

SP 800-56C says RFC 5869 specifies a version of its extraction-then-expansion procedure using HMAC for both steps. HKDF is that version.

Can I use BLAKE3 with SP 800-56C?

Not for an approved method. SP 800-56C's tables list the SHA-1, SHA-2 and SHA-3 hash functions and KMAC. BLAKE3 is not among them.

Does HKDF-SHA-256 limit a key to 128-bit security?

No. SP 800-56C lists HMAC-SHA-256 as supporting security strengths from 112 to 256 bits.

What is the salt for?

In the two-step method the salt keys the extraction MAC. A fresh random salt per session means a repeated shared secret would still produce different keys.

One-step or two-step?

Both are approved. The two-step method fits naturally when several keys are derived from one shared secret, using one extraction and several expansions with distinct FixedInfo.

Sources

  1. NIST SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, NIST, August 2020
  2. NIST SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, NIST, April 2018
  3. NIST SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions, NIST
  4. RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function (HKDF), IETF, May 2010
  5. FIPS 202, SHA-3 Standard, NIST, August 2015

Related Articles

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY