Match the you need to the FIPS standard that actually specifies the algorithm.
This selector helps separate algorithm choice from implementation validation, module validation, protocol design, and procurement evidence.
Use this selector when a design review, supplier review, or architecture decision needs the right FIPS algorithm family for a . It does not certify a product or replace a FIPS 140-3 module review. Its output is the algorithm standard, parameter decision, intended use, and evidence boundary to check before making a public or audit claim.
The system owner or architect first records the governing federal requirement, contract, procurement rule, or internal policy and the service the system needs: confidentiality, message authentication, message digest, digital signature, key establishment, key derivation, or quantum-resistant migration. The standard or NIST recommendation changes with that service. If the requirement source or service is unknown, the selector outcome is "not ready for algorithm selection," not a guessed algorithm.
Keep the selector narrow. FIPS 197 specifies AES as a block cipher with AES-128, AES-192, and AES-256. FIPS 180-4 specifies SHA-1 and SHA-2 hash algorithms. FIPS 202 specifies SHA-3 hash functions and SHAKE extendable-output functions. FIPS 186-5 specifies classical digital signature algorithms, while FIPS 203, 204, and 205 specify post-quantum ML-KEM, ML-DSA, and SLH-DSA.
Sources (4)
Supports the AES algorithm choices and the distinction between AES-128, AES-192, and AES-256.
AES-128, AES-192, and AES-256
Supports SHA-1 and SHA-2 family hash-function coverage for digest decisions.
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
Supports SHA-3 hash functions and SHAKE extendable-output functions as separate selector branches.
SHAKE128 and SHAKE256
Supports treating MACs, KDFs, protocol KDFs, approved-service conditions, and their validation evidence as separate decisions rather than inferring them from AES or SHA selection.
approved security services
Use the following decision list as the selector output. It names the standard that can support the algorithm claim and the minimum detail to capture before the decision is reusable.
Do not turn this list into a validation claim. An algorithm standard can identify a FIPS-approved algorithm, but certificate evidence depends on the tested implementation, module boundary, operating environment, and the program under which the evidence was issued.
Sources (4)
Supports the classical digital signature selector branch and the need to identify the signature system.
generate a digital signature
Supports the post-quantum key-encapsulation branch and the ML-KEM parameter-set choices.
ML-KEM-512, ML-KEM-768, and ML-KEM-1024
Supports selecting ML-DSA for post-quantum digital signature use cases.
generate and verify digital signatures
Supports selecting SLH-DSA as the stateless hash-based post-quantum signature branch.
stateless hash-based digital signature algorithm
The selector output is an algorithm decision record, not a product certification statement. The architect owns the service and parameter decision, the implementer identifies the library or hardware implementation and consuming protocol, and the assessor or buyer verifies certificate scope when the claim requires validation evidence. Record the source standard, selected parameter set, release version, owner, approval date, and exact claim text.
If the organization needs certificate evidence, check the relevant NIST validation record separately. A algorithm certificate supports tested algorithm implementation details; a FIPS 140-3 module validation claim belongs to the cryptographic module boundary and security requirements, not to this selector alone.
Sources (2)
Supports checking public algorithm-validation records separately from the selector decision.
Validation Number
Supports separating cryptographic module validation from an algorithm-standard selection.
security requirements for cryptographic modules
This selector helps create a narrow algorithm decision record before making validation, module, supplier, or public claims.
Convert selector decisions into scoped evidence requests, owner assignments, and review tasks.
Use cited NIST sources to resolve algorithm, parameter, and validation-boundary questions before implementation.
Check whether algorithm, implementation, module, and certificate claims are being kept at the right level.
Most selector errors come from compressing several different claims into one sentence. Avoid saying that a product, cloud service, protocol, or procurement item is FIPS-approved just because it uses an algorithm named in a FIPS publication.
Write the claim at the correct layer. The algorithm standard supports the primitive. The implementation evidence supports the tested implementation. The module certificate supports a defined cryptographic module boundary. Protocol and product claims need their own design evidence.
Sources (3)
Supports narrowing AES claims to the AES configurations named by the standard.
Advanced Encryption Standard (AES)
Supports separating SHA-3 and SHAKE algorithm claims from broader protocol or product claims.
Permutation-Based Hash and Extendable-Output Functions
Supports the warning that module validation is a separate claim with its own boundary.
four increasing, qualitative levels of security
Review this checklist before approving an architecture decision, supplier statement, or public FIPS algorithm claim. Each item should be answered with a source, configuration record, or certificate reference when a validation claim is being made.
Sources (3)
Supports the final certificate-scope check when the selector result is used in evidence review.
Validation Number
Supports recording the selected ML-KEM parameter set for post-quantum key-establishment decisions.
Module-Lattice-Based Key-Encapsulation Mechanism
Supports recording the selected stateless hash-based signature branch and parameter choices.
Stateless Hash-Based Digital Signature Standard
"Validation Number"
"security requirements for cryptographic modules"
"four increasing, qualitative levels of security"
"Advanced Encryption Standard (AES)"
"AES-128, AES-192, and AES-256"
"SHA-3 Standard"
"SHAKE128 and SHAKE256"
"Permutation-Based Hash and Extendable-Output Functions"
"ML-KEM-512, ML-KEM-768, and ML-KEM-1024"
"Module-Lattice-Based Key-Encapsulation Mechanism"
"Stateless Hash-Based Digital Signature Standard"
"stateless hash-based digital signature algorithm"
"Secure Hash Standard"
"SHA-1, SHA-224, SHA-256, SHA-384, SHA-512"
"Digital Signature Standard"
"generate a digital signature"
"Module-Lattice-Based Digital Signature Standard"
"generate and verify digital signatures"
"approved security services"
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.
Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims.
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.
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.