Artifact GuideGLOBALFIPS-approved cryptographic algorithm requirements

FIPS KDF and MAC coverage for validated modules

Use this page to separate approved KDF and MAC algorithm coverage from FIPS 140-3 module validation, service indicators, self-tests, and security policy evidence.

Grounded in NIST FIPS 140-3, CMVP implementation guidance, CAVP validation expectations, and FIPS 202 HMAC/SHA-3 guidance.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

KDF and MAC coverage should be documented at the module service level, not as a broad claim that a library is FIPS-compliant. The useful evidence is a map of each key-derivation or message-authentication service to its approved use case, CAVP or CVL evidence, cryptographic algorithm self-test requirement, service indicator, and Security Policy wording.

Section 1

Define which KDF or MAC service is being claimed

Start by naming the exact service: HMAC, truncated HMAC, KBKDF under SP 800-108, PBKDF under SP 800-132, KDA under SP 800-56C, a protocol KDF such as TLS, or a key-wrapping construction that combines encryption with HMAC, CMAC, or KMAC.

FIPS 140-3 requires conforming cryptographic modules to employ approved security functions. CMVP implementation guidance then makes the evidence more granular: approved security services need indicators, and the module Security Policy must list approved and non-approved services with the details needed to interpret those indicators.

Record the service name, callable API or operation, algorithm family, mode, underlying hash or auxiliary function, and whether the service is approved, allowed, non-approved but allowed, or not available in approved mode.
For KDFs, distinguish SP 800-108 derivation from a pre-shared key, SP 800-56C KDA used in key establishment, SP 800-132 password-based derivation for storage applications, and protocol KDFs listed as CVL components.
For MACs, distinguish full-length HMAC from truncated HMAC and record the hash family, tag length, HMAC key strength, and whether CAVP testing covers the truncated form.
Tie every public or procurement statement to the module boundary and tested operational environment; an algorithm certificate is not the same thing as a validated cryptographic module.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Defines approved security functions for conforming cryptographic modules and distinguishes module validation from general algorithm approval.

CMVP Implementation Guidance for FIPS 140-3

Explains service indicators, approved security services, Security Policy listings, KDF self-tests, truncated HMAC, and KDF-specific CMVP guidance.

Section 2

Map each KDF to the right approved-use lane

The most common KDF error is treating all key derivation as one bucket. CMVP guidance separates key derivation from a pre-shared key, key derivation during approved key establishment, password-based derivation for storage, and protocol-specific KDF components.

SP 800-108 KDFs are approved for deriving new keys from existing keying material when the key derivation key has been generated, entered, or established by a method approved or allowed in approved mode. They are not for directly generating asymmetric keys. SP 800-56C KDA belongs to key-establishment schemes, and CMVP guidance also identifies a no-iteration, no-counter one-step KDF variation with CAVP testing under KDA OneStepNoCounter.

KBKDF: document the SP 800-108 option, PRF, key derivation key source, derived-key use, and CAVP certificate coverage.
KDA: document whether the module implements one-step, two-step, or OneStepNoCounter SP 800-56C behavior, the auxiliary function, length limits, and key-establishment scenario.
PBKDF: document that SP 800-132 password-based derivation is used only for storage applications, with Security Policy justification for password/passphrase length and iteration-count choices.
TLS KDF: record whether the implementation supports RFC 5246 or RFC 7627 extended master secret behavior; CMVP guidance says untested TLS 1.2 KDF versions must not be used in approved mode.

Sources for this answer

CMVP Implementation Guidance for SP 800-108 KDFs

IG D.M states how SP 800-108 KDFs fit when deriving new keys from existing keying material in approved mode.

NIST SP 800-53 Rev. 5 key establishment discussion

SC-12 points implementers to SP 800-56A, SP 800-56B, and SP 800-56C for key-establishment schemes and key-derivation methods.

Section 3

Document MAC coverage without overclaiming HMAC approval

HMAC coverage needs more than naming the hash. CMVP guidance requires a CAST for implemented HMAC using at least one implemented SHA-1, SHA-2, or SHA-3 algorithm, and it gives separate rules for truncated HMAC use in approved mode.

For truncated HMAC, the page evidence should show the leftmost tag length, CAVP validation of the applicable truncated HMAC, Security Policy disclosure, and key-strength limits. CMVP guidance allows approved truncated HMAC forms when the output is truncated to at least 32 leftmost bits, while also noting that truncations below 64 bits are discouraged by SP 800-107rev1.

Capture the HMAC variant, hash family, tag length, key generation method, key strength, and whether the same implementation is also embedded inside a KDF, DRBG, protocol, or key-wrap service.
For HMAC-SHA-3, include the FIPS 202 input block size used by the HMAC specification and avoid describing SHAKE128 or SHAKE256 as approved hash functions.
When HMAC, CMAC, or KMAC is used with encryption for key wrapping, show that the entire wrapped message is authenticated and that the relevant algorithms have CAVP certificate evidence.
Do not imply that a MAC used inside one approved service automatically makes every service that calls the same primitive approved.

Sources for this answer

CMVP Implementation Guidance on truncated HMAC

IG C.D gives the approved-mode conditions for truncated HMAC, including CAVP validation and Security Policy disclosure.

NIST FIPS 202 SHA-3 Standard

Provides SHA-3 HMAC context and states that SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are approved hash functions.

Recommended next step

Operationalize KDF and MAC coverage

Use this FIPS KDF and MAC coverage map to collect service-level evidence, certificate references, self-test notes, and Security Policy language before making approved-mode claims.

Assessment workflow

Open Assessment Autopilot for FIPS evidence

Convert KDF and MAC coverage into scoped evidence requests, owner assignments, and review gates.

Explore next step

Research workflow

Research FIPS source questions

Use cited NIST and CMVP source material to resolve KDF, MAC, CAVP, and service-indicator questions before implementation.

Explore next step

Talk to Sorena

Talk through FIPS algorithm coverage

Review module scope, certificate evidence, approved-mode wording, and the next validation evidence actions with Sorena.

Explore next step

Section 4

Build the evidence table reviewers will expect

A reviewer should be able to trace each claimed KDF or MAC service from the Security Policy to the CAVP or CVL evidence and back to the shipped module configuration. The evidence table should not just say approved; it should explain the approved manner of use.

For FIPS 140-3, CMVP guidance on algorithm certificate binding is especially important. The CAVP certificate has to match the name and version of the validated algorithm implementation and the tested operational environment, and the embedded implementation must not be modified when integrated into the module under test.

Columns to include: service, algorithm or component, standard or IG lane, approved-use condition, operational environment, CAVP or CVL certificate number, CAST requirement, service indicator, Security Policy section, and exception notes.
For software modules, compare operating system, platform, processor, and hypervisor details where relevant before reusing CAVP evidence.
For each KDF or MAC service, record whether the CAST is direct, covered by a higher-level algorithm self-test, or specifically required by IG 10.3.A notes for KDFs and TLS KDF modes.
For services that can be used in approved and non-approved ways depending on caller input, document the approved-use rules in the Security Policy and expose an unambiguous service indicator.

Sources for this answer

CMVP Implementation Guidance on algorithm certificate binding

IG 2.3.A describes how algorithm validation certificates bind to module configuration and operational environment during FIPS 140-3 testing.

NIST CAVP validation search

Public search entry point for checking CAVP algorithm validation records before citing certificate evidence.

Section 5

Avoid common KDF and MAC coverage gaps

Most coverage gaps are caused by collapsing separate CMVP concepts into one compliance sentence. Keep algorithm validation, module validation, approved-mode service use, Security Policy wording, and operational-environment binding separate.

Use the checklist below as a release or audit gate before publishing FIPS KDF or MAC claims, responding to procurement questions, or preparing module evidence.

Do not cite a CAVP certificate unless the algorithm implementation, version, and tested operational environment match the module configuration being claimed.
Do not describe SP 800-108 as a general asymmetric-key generator; CMVP guidance limits it to deriving new keys from existing keying material.
Do not use a TLS 1.2 KDF version in approved mode when that version is not CAVP tested for the module.
Do not treat an HMAC truncation as approved unless the truncated form is CAVP validated, disclosed in the Security Policy, and uses an HMAC key with acceptable strength.
Do not rely on a Security Policy paragraph alone as the service indicator; CMVP guidance says the module must provide an externally accessible, unambiguous indication.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the gap checks for service indicators, SP 800-108 KDF limits, TLS KDF testing, CAST expectations, and truncated HMAC disclosure.

NIST FIPS 140-3 security requirements for cryptographic modules

Primary FIPS 140-3 source for approved security function requirements within conforming cryptographic modules.

Primary sources