A practical guide for selecting , , or functions and keeping the evidence clean for , ACVP, and FIPS 140-3 reviews.
Use it to separate algorithm conformance from module validation, protocol requirements, procurement wording, and internal migration policy.
Choose the hash from the consuming construction first. FIPS 180-4 currently specifies SHA-1 and the family; FIPS 202 specifies four hash functions and two extendable-output functions. These FIPS publications govern covered U.S. federal uses and are available for non-federal adoption, but a protocol, signature scheme, KDF, contract, or internal policy may impose the narrower choice. Record the exact function, digest or output length, protocol or construction, tested implementation, operational environment, and module boundary. A standardized hash name does not by itself prove that the implementation, product, protocol, or FIPS 140-3 service is validated.
FIPS 180-4 specifies SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 specifies SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. The and suffixes identify fixed digest lengths. In SHAKE128 and SHAKE256, the suffix indicates the security strength the XOF can generally support; the caller still chooses the output length.
Record the consuming use case before selecting the primitive. A hash used inside a digital signature, HMAC, KDF, pseudorandom bit generator, firmware integrity mechanism, certificate profile, or protocol transcript inherits requirements from that higher-level standard. It may also require domain separation, a minimum output length, a specific algorithm revision, or different validation coverage. If the higher-level construction names one function, do not substitute another merely because both functions appear in a FIPS publication.
Sources (3)
Identifies the SHA-1 and SHA-2 algorithms covered by the Secure Hash Standard.
This Standard specifies secure hash algorithms
Identifies SHA-3 hash functions and SHAKE extendable-output functions.
SHAKE128 and SHAKE256 are approved XOFs
States that NIST decided to revise FIPS 180-4 and remove the SHA-1 specification; the announcement is a revision decision, not the revised standard.
For assurance and procurement, split the claim into two layers. The public entry can support the tested hash implementation, while ACVP and ACVTS artifacts are supporting test records. The cryptographic module that exposes the service is validated separately by against FIPS 140-3. An algorithm certificate does not prove that the product, module boundary, operational environment, or approved mode is validated.
The evidence package should name the algorithm certificate, implementation version, tested operational environment, module certificate, approved service, and the exact product build that consumes the hash. If the algorithm implementation changes during integration, or if the operational environment differs from the tested environment, the existing algorithm evidence may not carry forward without retesting or validation review.
Sources (2)
Supports distinguishing CAVP algorithm records from CMVP module certificates and tested operational environments.
Cryptographic Algorithm Validation Program
Supports FIPS 140-3 as the module-security standard, not a standalone hash algorithm certificate.
security requirements for cryptographic modules
The consuming standard and required security strength usually control the choice. SHA-256 and SHA-384 commonly appear because protocols and signature schemes specify them. offers a Keccak-based design that differs from , but FIPS 202 does not make it a mandatory replacement. is appropriate only when the construction permits an XOF and fixes an output length that meets its security target. If no controlling construction permits the proposed function, stop the selection and record the design gap rather than treating a standalone FIPS citation as approval.
Write the decision record so a reviewer can reproduce the reasoning without hidden context. The record should state the function name, digest or output length, input domain, consuming construction, security-strength target, validation evidence, and migration trigger.
Sources (2)
Supports SHA-2 family digest lengths and the use of secure hashes with signatures, MACs, and random bit generation.
generation and verification of digital signatures
Supports SHA-3 as a supplement to SHA-1 and SHA-2, and SHAKE as an extendable-output function.
supplement the hash functions that are specified in FIPS 180-4
Use the hash selection, validation, module-boundary, and change-control notes as a shared evidence checklist before publishing a FIPS claim.
Convert SHA-2, SHA-3, and SHAKE decisions into accountable evidence tasks and review checkpoints.
Resolve hash-family, CAVP, ACVP, and FIPS 140-3 boundary questions before implementation.
Review the selected hash functions, validation evidence, module boundaries, and change triggers with Sorena.
A useful hash evidence pack is more than a source citation. It should connect the standard to the actual implementation, validation certificate, module boundary, service name, and change-control record. This is what prevents an auditor or customer from having to guess whether the hash claim applies to the shipped build.
For FIPS 140-3 contexts, the evidence should also show whether the service runs in approved mode and whether the module Security Policy lists the hash algorithm or integrity mechanism in the relevant service table. If the hash comes through a bound or embedded module, keep the referenced module name, certificate number, version, and used functionality explicit.
Sources (2)
Supports evidence requirements for algorithm certificate binding, implementation version, and operational environment.
Supports approved security functions and the module-level assurance boundary.
shall employ Approved security functions
Hash claims often fail because the evidence covers a narrower object than the wording. Name the function, construction, implementation, environment, and module service instead of expanding an algorithm citation into a product claim.
Sources (2)
Supports the distinction between SHA-3 hash functions and SHAKE XOF approval language.
the XOFs are not approved as hash functions
Supports caution around operational environment and algorithm-certificate binding.
"Cryptographic Algorithm Validation Program"
"SHA3-224, SHA3-256, SHA3-384, and SHA3-512"
"SHAKE128 and SHAKE256 are approved XOFs"
"supplement the hash functions that are specified in FIPS 180-4"
"the XOFs are not approved as hash functions"
"security requirements for cryptographic modules"
"shall employ Approved security functions"
"This Standard specifies secure hash algorithms"
"generation and verification of digital signatures"
AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.
How CAVP algorithm validation, the ACVP protocol, the ACVTS test system, and CMVP module validation fit together without overstating a FIPS claim.
Workflow for collecting CAVP validation evidence and ACVP/ACVTS test records: implementation identity, tested parameters, environments, and CMVP handoff records.
Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries.
Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP evidence.
A cited workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.
Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase.
Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status.
Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope.
Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries.
Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records.
Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records.
Answers to common FIPS algorithm questions: approved security functions, CAVP validation, CMVP module scope, AES modes, SHA-2, SHA-3, signatures, and post-quantum algorithms.
Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries.
An official source guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ.
Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries.
Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries.
Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required.
Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.
FAQ on how FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA fit FIPS-approved cryptographic algorithm planning, implementation evidence, and validation checks.
What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers.
How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
Identify SHA-1 and SHA-2 in FIPS 180-4 and SHA-3 and SHAKE in FIPS 202, then check current-use status and CAVP/CMVP evidence separately.
Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.
FIPS 197 defines AES as a FIPS-approved block cipher, but AES use alone is not the same as CAVP algorithm testing or FIPS 140-3 module validation.