WorkflowGLOBALFIPS cryptographic algorithms

FIPS approved algorithm selector workflow

A practical way to choose approved cryptographic algorithms by service type, standard, parameter set, module boundary, and validation evidence.

Use it to structure engineering and assurance review. Do not treat algorithm approval as proof that a module, product, protocol, or deployment is FIPS 140-3 validated.

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 workflow when a design review needs to decide which FIPS or NIST-approved cryptographic algorithm family fits a specific service. It separates the algorithm question from adjacent questions about modes of operation, parameter sets, CAVP testing, cryptographic module validation, approved-mode indicators, and deployment boundary.

Section 1

Start with the cryptographic service, not the algorithm name

The selector starts by naming the service the module or product will provide: encryption, hashing, digital signature, key establishment, key derivation, random bit generation support, or protocol component. That service determines which FIPS or NIST recommendation is relevant and which evidence can support the claim.

Keep the claim narrow. AES in FIPS 197 specifies a block cipher with AES-128, AES-192, and AES-256, but the standard also says AES is used with a FIPS-approved or NIST-recommended mode of operation. A hash decision should point to FIPS 180-4 or FIPS 202. Signature decisions should distinguish FIPS 186-5, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, and any application-level assurance requirements. Key-encapsulation decisions should identify the FIPS 203 ML-KEM parameter set.

Write one selector row per service, not one row per library or vendor package.
Record the source standard, algorithm family, mode or variant, parameter set, and intended security service.
Flag anything that is only a component or subroutine, such as K-PKE inside ML-KEM or WOTS+, XMSS, FORS, and hypertree components inside SLH-DSA.
Do not describe an implementation as validated unless the evidence names the relevant CAVP certificate, CMVP certificate, operational environment, and module boundary.

Sources for this answer

NIST FIPS 197-upd1 Advanced Encryption Standard

Supports AES scope, key sizes, 128-bit block size, and the need to use AES with an approved or recommended mode.

NIST FIPS 180-4 Secure Hash Standard

Supports SHA-1, SHA-2 family names, and federal secure-hash applicability alongside FIPS 202.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard

Supports ML-KEM service scope and approved parameter-set selection.

Section 2

Selector table for common FIPS algorithm choices

Use this table as the first pass before library or vendor selection. It is intentionally limited to claims supported by the standards; implementation status and validated use still need separate evidence.

Service | Candidate source | Decision detail to record | Evidence to request

Symmetric encryption | FIPS 197 plus the applicable mode recommendation | AES-128, AES-192, or AES-256, mode, IV or nonce handling, key management path | CAVP algorithm certificate, module Security Policy, mode documentation

Hashing or digest support | FIPS 180-4 or FIPS 202 | SHA-2 or SHA-3/SHAKE function, digest length, whether it is standalone or used inside another algorithm | CAVP certificate or module evidence for the function actually used

Classical signatures | FIPS 186-5 | RSA, ECDSA, or EdDSA use, key size or curve, hash function, key-generation assurance | Signature algorithm validation and public/private key assurance evidence

Post-quantum KEM | FIPS 203 | ML-KEM-512, ML-KEM-768, or ML-KEM-1024, input checking, key handling, encapsulation or decapsulation use | Parameter-set decision, implementation validation status, module boundary

Post-quantum signatures | FIPS 204 or FIPS 205 | ML-DSA or SLH-DSA, parameter set, pure or pre-hash variant where relevant | Signature validation evidence and approved hash or XOF evidence when pre-hashing is used

Treat the selector as a control input, not a certificate substitute.
When the standard says NIST will develop or provides validation-program information, check the live CAVP and CMVP records before making an implementation claim.
For pre-hash signature variants, record the approved hash function or XOF used to create the digest.
For PQC choices, record why the selected parameter set fits the application rather than copying the strongest available option into every service.

Sources for this answer

NIST FIPS 186-5 Digital Signature Standard

Supports classical digital-signature scope and validation-program distinction.

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard

Supports ML-DSA as an approved post-quantum digital-signature algorithm and parameter-set family.

NIST FIPS 205 Stateless Hash-Based Digital Signature Standard

Supports SLH-DSA scope, parameter-set approval, and the distinction between SLH-DSA and its components.

Recommended next step

Build a defensible FIPS algorithm selection record

Use the selector output to assign evidence owners, identify validation gaps, and keep algorithm claims aligned with module boundaries and certificates.

Assessment workflow

Open Assessment Autopilot for FIPS algorithm evidence

Convert selector rows into owners, evidence requests, gap statements, and review checkpoints.

Explore next step

Research workflow

Research FIPS source questions

Use official FIPS and CMVP material to resolve algorithm, parameter-set, and validation-evidence questions.

Explore next step

Talk to Sorena

Talk through FIPS algorithm selection

Review service scope, algorithm choices, validation evidence, and boundary caveats with Sorena.

Explore next step

Section 3

Evidence checks before calling a service approved

After a candidate algorithm is selected, verify whether the implementation evidence matches the exact service. FIPS 140-3 Implementation Guidance states that CAVP addresses testing of approved security functions and approved sensitive security parameter generation and establishment methods referenced by the SP 800-140 series.

A CAVP algorithm certificate is still not the same thing as a FIPS 140-3 module certificate. The IG states that an algorithm validation certificate identifies the validated algorithm implementation and tested operational environment. It also states that the tested operational environment must be identical to, or fully included in, the cryptographic module environment being tested, subject to the stated rules.

Match the certificate to the algorithm implementation name, version, processor or accelerator path, and operational environment.
Match the module claim to the cryptographic boundary, service list, approved and non-approved service separation, and Security Policy.
For approved-mode claims, verify the service indicator and the rule that non-approved security functions are not used in approved mode.
For protocol claims, check the component list instead of assuming a protocol version makes each KDF, MAC, cipher, or signature use approved.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the distinction between CAVP algorithm testing, operational environments, approved-mode indicators, and FIPS 140-3 module evidence.

NIST CAVP validation search

Public source to look up algorithm validation records before relying on a certificate number.

NIST FIPS 140-3 security requirements for cryptographic modules

Primary FIPS 140-3 source for module-level security requirements; use with CMVP guidance for approved-mode evidence.

Section 4

Decision gates for the selector workflow

Gate 1: Is the service in scope? Name the exact cryptographic service and reject selector rows that only name a broad product feature such as secure storage or secure transport.

Gate 2: Is the source family correct? Choose the FIPS or NIST source that covers the service: AES, secure hash, digital signature, key encapsulation, KDF, MAC, random bit generation, or protocol component.

Gate 3: Are the mode, parameter set, and supporting functions specified? Record AES mode, hash or XOF, signature parameter set, KEM parameter set, approved RBG dependency, and pre-hash details where relevant.

Gate 4: Does evidence match the implementation? Compare CAVP records, CMVP certificate and Security Policy text, service indicators, operational environment, hardware acceleration path, and module boundary.

Gate 5: What claim is allowed? The final row should say what is selected, what is validated or not yet validated, which boundary the evidence covers, and what change would reopen the decision.

Stop the workflow when the use case cannot be tied to a specific service and source standard.
Do not approve a selector row that lacks parameter-set detail for ML-KEM, ML-DSA, or SLH-DSA.
Do not carry a vendor certificate into a different module, platform, accelerator path, or operating environment without matching evidence.
Do not use the selector to make export, procurement acceptance, or customer compliance guarantees; it only documents the algorithm and evidence decision.

Sources for this answer

NIST FIPS 202 SHA-3 Standard

Supports SHA-3 and SHAKE choices when the service needs a hash or extendable-output function.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard

Supports the need to select an ML-KEM parameter set and avoid standalone K-PKE claims.

CMVP Implementation Guidance for FIPS 140-3

Supports approved-mode separation and service indicator review.

Section 5

Selector record template

Copy these fields into the design review or assurance record for each cryptographic service. Leave a field blank only if the reviewer has explicitly marked it not applicable and explained why.

Field | Required entry

Service | Encryption, digest, signature generation, signature verification, KEM encapsulation, KEM decapsulation, KDF, MAC, DRBG, or protocol component

Source | FIPS or NIST publication and section or table used for the selection

Algorithm choice | Family, mode or variant, parameter set, key size, curve, hash, XOF, or supporting function

Implementation evidence | CAVP certificate, CMVP certificate, Security Policy entry, test result, or gap statement

Boundary | Module, operational environment, library version, accelerator path, platform, and calling service

Allowed claim | Exact wording the team can use internally or externally, with any caveat

Change trigger | Library update, compiler/platform change, accelerator change, parameter-set change, protocol change, module boundary change, or certificate-status change

Use a gap statement when validation evidence is not available instead of weakening the wording to imply approval.
Record negative decisions, especially non-approved algorithms kept only for interoperability or no-security-claimed use.
Tie every external claim to a source URL and an evidence artifact rather than to the selector workflow itself.
Review the selector record before release, customer questionnaires, audits, and module-validation submissions.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports boundary, operational-environment, approved-service, and non-approved-service evidence checks.

NIST CAVP validation search

Public source for confirming algorithm certificate records used in selector evidence.

NIST FIPS 205 Stateless Hash-Based Digital Signature Standard

Supports recording approved SLH-DSA parameter sets and component-use limitations.

Primary sources