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

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

Choose the cryptographic service first, then the governing FIPS or NIST publication, algorithm or scheme, mode, parameter set, and supporting functions. The cited FIPS publications control covered U.S. federal systems and are available for private and commercial adoption; a protocol profile, agency rule, contract, or application standard may narrow the allowed choice. After selection, verify the implementation through the Cryptographic Algorithm Validation Program (). When the claim concerns a validated cryptographic module, also verify the separate Cryptographic Module Validation Program () certificate, public Security Policy, operational environment, module boundary, and approved-service indicator. An approved algorithm standard does not validate a product, protocol, deployment, or module.

Section 1

Start with the cryptographic service, not the algorithm name

The system or product owner names the service the module or product will provide: encryption, hashing, digital signature, key establishment, key derivation, message authentication, random bit generation, or a protocol component. The cryptographic engineer records the exact algorithm, mode, parameter set, and dependencies. The assurance reviewer matches that design to and evidence. The service determines which FIPS or NIST publication applies and what evidence can support the resulting 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.
Keep algorithm and module claims separate. A record supports the listed algorithm implementation and operational environment. A module-level claim also needs the applicable certificate, Security Policy, module boundary, tested environment, approved services, and usage conditions.

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

This table is 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 | 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 | 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

Message authentication | FIPS 198-1 or the applicable NIST mode recommendation | HMAC or an approved block-cipher-based MAC, underlying hash or cipher, tag length, key handling | entry for the exact MAC and parameters plus module evidence when a module claim is made

Key derivation or protocol KDF | Applicable NIST recommendation or protocol-KDF reference recognized by guidance | KDF family, inputs, output length, protocol context, and whether use is component-limited | or Component Validation List (CVL) entry, usage restriction, Security Policy mapping, and protocol context

Random bit generation | SP 800-90A and applicable entropy-source requirements | Deterministic random bit generator (DRBG) construction, security strength, entropy source, personalization or nonce handling, reseed behavior | DRBG validation entry plus module entropy and Security Policy evidence

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

NIST Cryptographic Algorithm Validation Program

Explains CAVP validation scope, public-listing fields, ACVTS Production testing, and the boundary between algorithm and module validation.

CMVP Implementation Guidance for FIPS 140-3

Provides the approved-mode conditions and usage limits for algorithm components, protocol KDFs, SP 800-108 KDFs, random bit generation, MACs, and sensitive security parameter establishment within a FIPS 140-3 module.

Recommended next step

Build a 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 addresses testing of approved security functions and approved sensitive security parameter generation and establishment methods referenced by the SP 800-140 series.

A algorithm certificate is not a FIPS 140-3 module certificate. The guidance says an algorithm certificate identifies the validated algorithm implementation and tested operational environment. When that certificate is bound into a module undergoing FIPS 140-3 testing, the CAVP-tested environment must be identical to, or fully included in, the module's test environment under the guidance's stated rules. Do not apply that binding rule as a blanket claim that every unlisted product environment is validated.

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 .
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 a validation number, vendor, implementation, product type, included algorithms, and validation date before relying on supplier evidence.

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 records, certificate and Security Policy text, service indicators, operational environment, hardware acceleration path, and module boundary.

Gate 5: What claim is allowed? Choose one bounded outcome: rejected because the service or governing source is unclear; selected at design level but missing implementation evidence; matched to a named -tested implementation; or matched to a named -validated module whose approved service is used under its Security Policy conditions. Record the owner, covered boundary, allowed wording, open evidence, and changes that 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 | certificate, 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, procurements, and module-validation submissions, and reopen it after an algorithm, mode, parameter set, library, compiler, processor path, operational environment, protocol, module boundary, Security Policy, or certificate-status change.

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 the validation number, implementation, vendor, algorithm coverage, product type, and validation date recorded 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

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

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

"algorithm validation certificate states the name and version number"

NIST CAVP validation search

csrc.nist.gov

Referenced sections

Public source for confirming the validation number, implementation, vendor, algorithm coverage, product type, and validation date recorded in selector evidence.

NIST Cryptographic Algorithm Validation Program

csrc.nist.gov

Referenced sections