Artifact GuideGLOBALFIPS cryptographic algorithms

FIPS cryptographic algorithms Algorithm Selector

Match the cryptographic service you need to the FIPS standard that actually specifies the algorithm.

Use this selector to 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

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

Use this page when a design review, supplier review, or architecture decision needs the right FIPS algorithm family. The selector does not certify a product or replace a FIPS 140-3 module review; it identifies the algorithm standard, the parameter decision to record, and the evidence boundary to check before making a public or audit claim.

Section 1

Start with the cryptographic service, not the algorithm name

A FIPS algorithm decision should begin with the service the system needs: confidentiality, message digest, digital signature, key establishment, or quantum-resistant migration. The standard that supports the decision changes with that service.

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 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.
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.

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.
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

Use this selector to 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 should be an algorithm decision record, not a product certification statement. Record the source standard, selected parameter set, implementation or library, consuming protocol, release version, and the claim type being made.

If the organization needs certificate evidence, check the relevant NIST validation record separately. A CAVP 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: CAVP certificate or CMVP 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 CAVP or CMVP 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

Use 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 cryptographic service 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 CAVP or CMVP 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