Artifact GuideGLOBALFIPS cryptographic algorithms

FIPS cryptographic algorithms Algorithm Selector

Match the cryptographic service 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.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 25, 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 Jul 25, 2026

Overview

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.

Section 1

Start with the cryptographic service, not the algorithm name

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.

For symmetric encryption primitives, start with AES under FIPS 197 and record the selected key size.
For message authentication or key derivation, name the construction as well as its underlying primitive. HMAC, CMAC, KMAC, SP 800-108 KDFs, SP 800-56C KDA, and protocol KDFs have separate use and validation conditions; choosing SHA or AES alone does not select the service.
For message digests and hash-dependent services, choose between SHA-2 under FIPS 180-4 and SHA-3 or SHAKE under FIPS 202 based on the consuming protocol or design. Check current approved-use and transition sources for the exact function; FIPS 180-4 still specifies SHA-1, but that does not make every SHA-1 use currently approved.
For classical public-key signatures, use FIPS 186-5 and record the signature family, curve or modulus choices, hash function, and assurance source.
For post-quantum key establishment, use FIPS 203 ML-KEM and record ML-KEM-512, ML-KEM-768, or ML-KEM-1024.
For post-quantum signatures, use FIPS 204 ML-DSA or FIPS 205 SLH-DSA and record the parameter set, signature size impact, and relying protocol constraints.

Sources for this answer

NIST FIPS 197-upd1 Advanced Encryption Standard

Supports the AES algorithm choices and the distinction between AES-128, AES-192, and AES-256.

NIST FIPS 180-4 Secure Hash Standard

Supports SHA-1 and SHA-2 family hash-function coverage for digest decisions.

NIST FIPS 202 SHA-3 Standard

Supports SHA-3 hash functions and SHAKE extendable-output functions as separate selector branches.

CMVP Implementation Guidance for FIPS 140-3

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.

Section 2

Selector table for common FIPS algorithm decisions

Use the following decision table 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 the table 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.

Confidentiality primitive: FIPS 197 AES; capture AES-128, AES-192, or AES-256, plus the separate mode or protocol source used by the design.
Hash or digest primitive: FIPS 180-4 SHA-2 family or FIPS 202 SHA-3/SHAKE; capture digest or output length and the protocol that consumes it.
Message authentication or key derivation: select the construction and governing NIST source; capture the underlying hash, block cipher, or XOF, output or tag length, key source, protocol context, and approved-use conditions.
Classical digital signature: FIPS 186-5; capture RSA, ECDSA, or EdDSA-related choices, required hash functions, and key-assurance evidence.
Post-quantum key establishment: FIPS 203 ML-KEM; capture the selected parameter set and whether the integration is hybrid, migration-only, or production-bound.
Post-quantum digital signature: FIPS 204 ML-DSA or FIPS 205 SLH-DSA; capture parameter set, signature-size limits, verification path, and protocol support.

Sources for this answer

NIST FIPS 186-5 Digital Signature Standard

Supports the classical digital signature selector branch and the need to identify the signature system.

NIST FIPS 203 ML-KEM

Supports the post-quantum key-encapsulation branch and the ML-KEM parameter-set choices.

NIST FIPS 204 ML-DSA

Supports selecting ML-DSA for post-quantum digital signature use cases.

NIST FIPS 205 SLH-DSA

Supports selecting SLH-DSA as the stateless hash-based post-quantum signature branch.

Recommended next step

Operationalize the FIPS algorithm selector

This selector helps create a narrow algorithm decision record before making validation, module, supplier, or public claims.

Assessment workflow

Open Assessment Autopilot for FIPS algorithm evidence

Convert selector decisions into scoped evidence requests, owner assignments, and review tasks.

Explore next step

Research workflow

Research FIPS algorithm source questions

Use cited NIST sources to resolve algorithm, parameter, and validation-boundary questions before implementation.

Explore next step

Talk to Sorena

Review a FIPS algorithm selector decision

Check whether algorithm, implementation, module, and certificate claims are being kept at the right level.

Explore next step

Section 3

Evidence boundary for an algorithm selection

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.

Algorithm record: standard, algorithm family, parameter set, hash or output length, and reason for selection.
Implementation record: library, firmware, hardware accelerator, provider, version, platform, and enabled configuration.
Use-case record: protocol, data flow, key-management dependency, signature verification path, or key-establishment exchange that consumes the algorithm.
Validation record: certificate or module certificate only when the certificate scope matches the implementation and release being reviewed.
Change record: re-check the selector when the algorithm, parameter set, cryptographic library, module boundary, protocol, platform, or supplier changes.

Sources for this answer

NIST CAVP validation search

Supports checking public algorithm-validation records separately from the selector decision.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports separating cryptographic module validation from an algorithm-standard selection.

Section 4

Rules for avoiding overstated FIPS claims

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.

Say "uses AES-256 as specified in FIPS 197" only when the implementation actually uses the AES-256 configuration.
Do not cite FIPS 180-4 or FIPS 202 as proof that every protocol use of a hash function is appropriate.
Do not cite FIPS 186-5, 204, or 205 without naming the selected signature algorithm and parameter choices.
Do not use ML-KEM, ML-DSA, or SLH-DSA wording to imply complete post-quantum migration; record the integration and interoperability state separately.
Do not use a or link unless the certificate scope, version, platform, and boundary match the release under review.

Sources for this answer

NIST FIPS 197-upd1 Advanced Encryption Standard

Supports narrowing AES claims to the AES configurations named by the standard.

NIST FIPS 202 SHA-3 Standard

Supports separating SHA-3 and SHAKE algorithm claims from broader protocol or product claims.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the warning that module validation is a separate claim with its own boundary.

Section 5

Algorithm selector checklist

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.

Name the first: confidentiality, digest, digital signature, key establishment, or post-quantum migration.
Name the exact FIPS standard and algorithm family that supports the service.
Record required parameters: AES key size, hash or XOF output length, signature family, ML-KEM parameter set, ML-DSA parameter set, or SLH-DSA parameter set.
Record the implementation boundary: library, module, hardware, firmware, operating environment, protocol, and release.
Attach validation evidence only when the or record matches the implementation, version, configuration, and boundary being asserted.
Rewrite any broad procurement or marketing wording that treats algorithm approval as product, protocol, or module validation.

Sources for this answer

NIST CAVP validation search

Supports the final certificate-scope check when the selector result is used in evidence review.

NIST FIPS 203 ML-KEM

Supports recording the selected ML-KEM parameter set for post-quantum key-establishment decisions.

NIST FIPS 205 SLH-DSA

Supports recording the selected stateless hash-based signature branch and parameter choices.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

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.