---
title: "FIPS-approved cryptographic algorithms FAQ"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/faq"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/faq/items"
author: "Sorena AI"
description: "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."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS algorithms"
  - "CAVP validation"
  - "CMVP validation"
  - "AES"
  - "SHA-2"
  - "SHA-3"
  - "ML-KEM"
  - "ML-DSA"
  - "CAVP"
  - "CMVP"
  - "post-quantum cryptography"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# FIPS-approved cryptographic algorithms FAQ

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.

*FAQ* *GLOBAL* *FIPS-approved cryptographic algorithms*

## FIPS-approved cryptographic algorithms FAQ

Answers to practical questions about approved algorithms, CAVP certificates, CMVP module validation, approved mode, and algorithm evidence.

Use this page to separate standards facts from vendor claims, procurement language, and product-specific validation evidence.

FIPS algorithm questions often get blurred with FIPS 140-3 module claims. This FAQ separates the layers: a cryptographic algorithm may be specified in a FIPS publication, adopted in a NIST recommendation, or listed as an approved security function, while a product claim usually depends on the cryptographic module boundary, the services used in approved mode, and the validation evidence available for the implementation.

## Browse sub-FAQ modules

### [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md)

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.

- 3 items

### [FIPS Algorithm Procurement Evidence FAQ](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md)

What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers.

- 3 items

### [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md)

How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.

- 3 items

### [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md)

Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation.

- 3 items

### [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md)

Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.

- 3 items

### [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md)

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.

- 2 items

Browse all indexed questions: [/artifacts/global/fips-crypto-algorithms/faq/items](/artifacts/global/fips-crypto-algorithms/faq/items.md)

## All FAQ items

*Page 1 of 1. Showing 17 of 17 items.*

### [What do FIPS 203, FIPS 204, and FIPS 205 cover?](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md#what-do-fips-203-fips-204-and-fips-205-cover)

*Module: [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md)*

FIPS 203 covers ML-KEM, a module-lattice-based key-encapsulation mechanism used to establish a shared secret key over a public channel. It is the post-quantum key-establishment standard in this set, not a digital signature standard.

- Use FIPS 203 when the scoped function is ML-KEM key generation, encapsulation, or decapsulation.
- Use FIPS 204 when the scoped function is ML-DSA key generation, signature generation, signature verification, or the pre-hash variants supported by the standard.
- Use FIPS 205 when the scoped function is SLH-DSA key generation, signature generation, signature verification, or approved SHA2/SHAKE parameter-set use.

Sources for this answer:

- [NIST FIPS 203 ML-KEM standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf?ref=sorena.io) - Defines ML-KEM as the FIPS 203 key-encapsulation mechanism and lists ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
- [NIST FIPS 204 ML-DSA standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf?ref=sorena.io) - Defines ML-DSA as the FIPS 204 lattice-based digital signature algorithm and explains its federal signature-system applicability.
- [NIST FIPS 205 SLH-DSA standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf?ref=sorena.io) - Defines SLH-DSA as the FIPS 205 stateless hash-based digital signature algorithm and identifies its approved parameter-set family.

### [What implementation evidence should teams keep?](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md#what-implementation-evidence-should-teams-keep)

*Module: [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md)*

The evidence should show the algorithm, parameter set, module boundary, and interface actually used. A bare statement that a product is post-quantum or FIPS-ready is not enough because the NIST standards include parameter-set choices, input checks, approved random bit generation, private-key or decapsulation-key safeguards, and restrictions on exposing testing-only internal interfaces.

- Map each public claim to a scoped cryptographic function: ML-KEM key establishment, ML-DSA signatures, or SLH-DSA signatures.
- Store parameter-set evidence, implementation version, module boundary, operating environment, and whether the function is used in an approved mode.
- Keep test and design evidence separate from certification claims; passing internal tests or using an approved algorithm name does not by itself prove a module is CMVP-validated.

Sources for this answer:

- [NIST FIPS 203 ML-KEM standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf?ref=sorena.io) - Supports ML-KEM parameter-set, input-checking, randomness, and default ML-KEM-768 evidence requirements.
- [NIST FIPS 204 ML-DSA standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf?ref=sorena.io) - Supports ML-DSA parameter-set, signature verification, approved random bit generation, and intermediate-data handling evidence.
- [NIST FIPS 205 SLH-DSA standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf?ref=sorena.io) - Supports SLH-DSA SHA2/SHAKE parameter-set, key-generation randomness, signing, and verification evidence.

### [How should CAVP and CMVP validation claims be handled?](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md#how-should-cavp-and-cmvp-validation-claims-be-handled)

*Module: [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md)*

Use cautious wording. The three standards say NIST will develop validation programs to test implementations for conformance to the algorithms in this standard, and the CMVP implementation guidance adds cryptographic algorithm self-test requirements for ML-KEM, ML-DSA, and SLH-DSA. That supports planning and evidence collection, but it does not justify saying that a product, library, or cloud service is validated unless the relevant certificate or module listing supports that exact scope.

- Check the public CAVP validation search for algorithm evidence before citing an algorithm certificate.
- Check CMVP module documentation before claiming a module is FIPS 140-3 validated or that post-quantum functionality is inside the validated boundary.
- Record unresolved gaps explicitly, such as missing certificate scope, unsupported parameter set, non-approved mode, unvalidated module boundary, or supplier roadmap-only support.

Sources for this answer:

- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?orderBy=ValidationNumber&searchMode=validation&ref=sorena.io) - Public NIST search used to verify cryptographic algorithm validation evidence before citing a certificate.
- [NIST Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Public CMVP program source for module-validation context and module-level FIPS 140-3 evidence.
- [NIST FIPS 140-3 implementation guidance](https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements?ref=sorena.io) - Grounds the need to account for ML-KEM, ML-DSA, and SLH-DSA cryptographic algorithm self-tests in module validation work.

### [How should procurement teams handle FIPS algorithm evidence?](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md#how-should-procurement-teams-handle-fips-algorithm-evidence)

*Module: [FIPS Algorithm Procurement Evidence](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md)*

Treat a FIPS algorithm claim and a FIPS 140-3 module claim as related but different assertions. CAVP evidence supports a tested algorithm implementation; CMVP evidence supports a validated cryptographic module. A procurement file should show which claim the supplier is making and which public certificate or security policy supports it.

- Require the supplier to identify whether the claim is algorithm validation, module validation, or both.
- Match certificate evidence to the exact purchased version, platform, operating environment, and cryptographic boundary.
- Keep the module security policy with the procurement record because it explains approved and non-approved services, service indicators, and certificate scope.
- Reject unsupported shorthand such as "uses FIPS algorithms" when no CAVP certificate, CMVP certificate, or security-policy mapping is provided.

Sources for this answer:

- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use the public CAVP search to check algorithm certificate numbers, implementation names, versions, and operational environments cited by a supplier.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the distinction between CAVP-tested algorithm implementations and CMVP-validated cryptographic modules.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains why validated cryptographic modules are used as a procurement security metric for equipment containing cryptographic modules.

### [What evidence should teams collect from suppliers?](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md#what-evidence-should-teams-collect-from-suppliers)

*Module: [FIPS Algorithm Procurement Evidence](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md)*

Collect evidence that a reviewer can verify without relying on marketing language. The core packet should include the supplier's FIPS claim, the public CAVP algorithm certificate where algorithm validation is claimed, the public CMVP module certificate where module validation is claimed, the FIPS 140-3 security policy, and a product-to-certificate mapping that names the exact product build and deployment environment.

- Supplier claim: the exact statement being accepted, such as "module validated to FIPS 140-3" or "algorithm implementation validated by CAVP."
- Public certificate evidence: CAVP certificate numbers for algorithm implementations and CMVP certificate numbers for modules, with current status checked at review time.
- Security policy evidence: approved services, non-approved services, service indicators, algorithm lists, module versions, and operating environment scope.
- Product mapping: SKU, software or firmware version, deployment platform, cloud service configuration, and the component that actually invokes the approved security service.
- Change evidence: supplier notice and internal reassessment triggers for certificate status changes, algorithm transitions, module updates, platform additions, or audit findings.

Sources for this answer:

- [NIST SP 800-161 Rev. 1 Update 1](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Supports procurement clauses that define accepted evidence and verification methods for supplier requirements.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports collecting security-policy evidence for approved and non-approved services and externally accessible service indicators.
- [NIST FIPS 197 Advanced Encryption Standard](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Shows why an AES claim is not enough by itself: FIPS 197 specifies the algorithm, while implementation and module evidence must still be mapped to validation records.

### [What review checks prevent weak FIPS procurement files?](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md#what-review-checks-prevent-weak-fips-procurement-files)

*Module: [FIPS Algorithm Procurement Evidence](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md)*

The main review risk is accepting evidence that proves a different thing than the procurement claim. An AES certificate may support a specific algorithm implementation in a tested environment, but it does not by itself prove the purchased product is a FIPS 140-3 validated module or that every service in the product runs in an approved manner.

- Check that the certificate status is current enough for the procurement decision and is not being confused with a different module, version, or platform.
- Verify that approved-service indicators are documented and usable for the service the organization will call.
- Confirm that non-approved algorithms or services are not presented as approved security functions in the procurement response.
- For bound or embedded module claims, verify the referenced validated module, certificate number, version, and operational environment.
- Document gaps as procurement conditions, remediation tasks, compensating controls, or rejection reasons instead of turning them into unsupported validation claims.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports review triggers for historical or revoked module status, bound or embedded modules, and precise certificate identification.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this public search to verify that cited algorithm certificate numbers correspond to the implementation and environment in the procurement record.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports scoping review around cryptographic module security requirements rather than broad product-level marketing claims.

### [What does each validation certificate prove?](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md#what-does-each-validation-certificate-prove)

*Module: [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md)*

The CMVP implementation guidance draws a clear line between certificate types. CAVP tests and validates cryptographic algorithm implementations; the algorithm validation certificate states the implementation name, implementation version, and tested operational environment.

- Use CAVP evidence for the tested algorithm implementation, such as an AES, hash, signature, KDF, MAC, or DRBG implementation.
- Use CMVP evidence for a FIPS 140-3 cryptographic module claim, including the module boundary, security policy, approved services, status, and caveats.
- Do not convert a CAVP algorithm certificate into a product-level or module-level FIPS 140-3 validation claim.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Distinguishes CAVP algorithm validation certificates from CMVP cryptographic module validation certificates.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search page for checking algorithm validation records before citing a CAVP certificate.
- [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public search page for checking FIPS 140-3 and FIPS 140-2 cryptographic module validation records.

### [When does a certificate match a deployed implementation?](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md#when-does-a-certificate-match-a-deployed-implementation)

*Module: [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md)*

A validation certificate is a benchmark for the configuration and operational environment used during validation testing. For an algorithm implementation embedded in a module undergoing FIPS 140-3 testing, the guidance requires the algorithm implementation to remain unmodified and the CAVP-tested operational environment to be identical to, or fully included in, the module testing environment.

- Compare the certificate's algorithm implementation name and version with the implementation shipped in the product or module.
- Compare the certificate's tested operating system, platform, processor, and hypervisor details with the deployed or validated environment.
- Re-check evidence after code changes, library swaps, processor acceleration changes, operating-system changes, module-boundary changes, or certificate status changes.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the implementation, version, and operational-environment checks needed before reusing certificate evidence.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Defines FIPS 140-3 as the cryptographic-module security requirement set and explains the CMVP validation role.

### [How should certificate evidence be worded in reviews?](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md#how-should-certificate-evidence-be-worded-in-reviews)

*Module: [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md)*

Use wording that names the exact evidence and stops at what it proves. A safe evidence statement identifies the certificate type, certificate number or listing, vendor, module or implementation name, version, operational environment, validation status, and the date the public listing was checked.

- Keep CAVP certificate records with the algorithm implementation, parameters, certificate number, tested environment, and source URL.
- Keep CMVP certificate records with the module name, version, certificate number, security policy, status, approved-mode instructions, caveats, and source URL.
- Avoid claims that a whole application, cloud service, or product is FIPS validated unless the cited CMVP certificate and deployment configuration actually support that scope.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports certificate-scoped evidence wording and review triggers for implementation and environment changes.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports keeping module-validation evidence separate from algorithm-standard or algorithm-certificate evidence.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use the public CAVP listing for current algorithm certificate details rather than relying only on copied screenshots.

### [Which hash functions come from FIPS 180-4 and FIPS 202?](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md#which-hash-functions-come-from-fips-180-4-and-fips-202)

*Module: [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md)*

FIPS 180-4 is the Secure Hash Standard for SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 adds the SHA-3 family: SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus the SHAKE128 and SHAKE256 extendable-output functions.

- Use FIPS 180-4 when the decision is about SHA-1 or SHA-2 digest functions.
- Use FIPS 202 when the decision is about SHA-3 hash functions or SHAKE extendable-output functions.
- Do not treat the standard name alone as proof that a product, library, or module is validated.

Sources for this answer:

- [NIST FIPS 180-4 Secure Hash Standard](https://csrc.nist.gov/pubs/fips/180-4/upd1/final?ref=sorena.io) - Identifies the SHA-1 and SHA-2 algorithms covered by the Secure Hash Standard.
- [NIST FIPS 202 SHA-3 Standard](https://csrc.nist.gov/pubs/fips/202/final?ref=sorena.io) - Identifies the SHA-3 hash functions and the SHAKE extendable-output functions.

### [What evidence proves the hash implementation is approved?](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md#what-evidence-proves-the-hash-implementation-is-approved)

*Module: [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md)*

The useful evidence is not a screenshot that says SHA-256 or SHA3-256 exists. Record the CAVP algorithm certificate or validation result for the exact implementation name, version, algorithm, parameters, and tested operational environment.

- Capture the algorithm name, certificate number or validation entry, implementation version, vendor, and tested operating environment.
- For software modules, compare the CAVP operating environment with the module operating environment before relying on the certificate.
- For a FIPS 140-3 claim, tie the hash evidence to the validated module boundary and approved services shown in CMVP-facing documentation.

Sources for this answer:

- [NIST Cryptographic Algorithm Validation Program](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Program source for CAVP algorithm implementation validation evidence.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://csrc.nist.gov/pubs/fips/140-3/final?ref=sorena.io) - Distinguishes FIPS 140-3 module validation scope from the underlying approved algorithms used by the module.
- [NIST Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program page for CMVP module validation, which is separate from CAVP algorithm implementation testing.

### [Where do teams make mistakes with SHA-3 and SHAKE?](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md#where-do-teams-make-mistakes-with-sha-3-and-shake)

*Module: [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md)*

The main mistake is treating every FIPS 202 function as interchangeable. SHA-3 hash functions can appear as standalone functions or inside approved higher-level algorithms when the relevant testing path supports that use. CMVP implementation guidance is more restrictive for SHAKE128 and SHAKE256: outside algorithm standards that explicitly allow them, SHAKE functions are used as standalone algorithms.

- Do not substitute SHAKE for a fixed-length hash unless the higher-level algorithm standard or NIST guidance supports that use.
- Do not list a higher-level algorithm as approved merely because one internal hash function has a CAVP certificate.
- Do not reuse a hash validation across a changed implementation or operating environment without checking the certificate scope.

Sources for this answer:

- [NIST FIPS 202 SHA-3 Standard](https://csrc.nist.gov/pubs/fips/202/final?ref=sorena.io) - Explains that SHA-3 functions supplement FIPS 180-4 hash functions and that SHAKE output length is application-dependent.
- [NIST Cryptographic Algorithm Validation Program](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Program source for checking whether an algorithm implementation has CAVP validation evidence.
- [NIST Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Supports keeping module validation status and approved-mode service claims separate from standalone hash-function selection.

### [Which signature algorithms does FIPS 186-5 support?](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md#which-signature-algorithms-does-fips-186-5-support)

*Module: [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md)*

Use FIPS 186-5 when the decision is about digital signature generation or verification for RSA, ECDSA, deterministic ECDSA, EdDSA, or HashEdDSA. The standard also states that DSA is no longer approved for digital signature generation, although DSA may be used to verify signatures generated before the implementation date.

- Record whether the service performs signature generation, signature verification, or both.
- Separate RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, and legacy DSA verification decisions; do not collapse them into a generic signature claim.
- For RSA, document the modulus length, scheme such as RSASSA-PSS or RSASSA-PKCS1-v1.5, approved hash or XOF choice, and whether key generation is performed by the module.

Sources for this answer:

- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Defines the approved digital signature standard and states that DSA is no longer approved for signature generation.
- [NIST FIPS 140-3 Implementation Guidance](https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Clarifies RSA signature parameter sizes, CAVP testing expectations, and Security Policy documentation for FIPS 140-3 module submissions.

### [What evidence should support a FIPS 186-5 signature claim?](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md#what-evidence-should-support-a-fips-186-5-signature-claim)

*Module: [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md)*

A useful evidence package starts with the standard citation but does not stop there. Keep the FIPS 186-5 algorithm decision, the CAVP algorithm-validation record, and the CMVP module claim as separate records that are linked only when the implementation name, version, parameters, and operating environment match.

- Use CAVP evidence to support the tested algorithm implementation, not to claim that the whole product or module is FIPS 140-3 validated.
- Use CMVP evidence to support module validation, approved-mode operation, module boundary, and approved-service claims.
- Refresh the evidence when the implementation version, operating environment, module boundary, processor acceleration path, key-generation path, or approved-service listing changes.

Sources for this answer:

- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search source for checking algorithm validation entries for signature implementations, modes, parameters, and environments.
- [NIST Cryptographic Module Validation Program](https://www.nist.gov/cmvp?ref=sorena.io) - Program source for cryptographic module validation, which is distinct from algorithm implementation testing.
- [NIST FIPS 140-3 Implementation Guidance](https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Explains that CAVP algorithm certificates identify implementation details and tested operational environments for module submissions.

### [What FIPS 186-5 signature mistakes should teams avoid?](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md#what-fips-186-5-signature-mistakes-should-teams-avoid)

*Module: [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md)*

The first mistake is key reuse. FIPS 186-5 says digital signature key pairs must not be used for other purposes such as key establishment, and it repeats that RSA and ECDSA signature keys are signature-only. A key inventory should therefore show a signature-only purpose rather than a shared public-key bucket.

- Do not use a signature key pair for key establishment, encryption, or other non-signature purposes.
- Do not claim DSA signature generation as approved under FIPS 186-5; limit DSA to the legacy verification context supported by the standard.
- Do not reuse a CAVP certificate across a different implementation, version, operating environment, parameter set, or module boundary without confirming the scope.

Sources for this answer:

- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Supports key-purpose separation, assurance checks before accepting signatures as valid, and the limits of conformance claims.
- [NIST FIPS 140-3 Implementation Guidance](https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Clarifies that approved-service indicators may depend on the signature algorithm, hash algorithm, and key size used by the service.

### [What does FIPS 197 actually define?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md#what-does-fips-197-actually-define)

*Module: [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md)*

FIPS 197 defines the Advanced Encryption Standard as a symmetric block cipher for protecting electronic data. The standard specifies three AES variants: AES-128, AES-192, and AES-256.

- Use FIPS 197 to identify the AES algorithm family and the allowed AES key sizes.
- Record the AES mode separately because FIPS 197 says AES shall be used with a FIPS-approved or NIST-recommended mode of operation.
- Do not describe Rijndael options outside AES-128, AES-192, or AES-256 as FIPS 197 AES.

Sources for this answer:

- [NIST FIPS 197-upd1 Advanced Encryption Standard](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Defines AES as the FIPS-approved algorithm and specifies AES-128, AES-192, AES-256, 128-bit blocks, and approved or recommended mode usage.

### [Does using AES mean a module is FIPS validated?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md#does-using-aes-mean-a-module-is-fips-validated)

*Module: [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md)*

No. FIPS 197 defines the AES algorithm; it is not a cryptographic module certificate. A product can use AES while still needing separate evidence about the implemented algorithm, module boundary, operational environment, approved services, and FIPS 140-3 validation status.

- Treat an AES library name, marketing claim, or source-code reference as insufficient by itself.
- Confirm the tested AES implementation, mode, key sizes, certificate identifier, vendor, version, and operational environment in the applicable CAVP or CMVP record.
- When the claim is about FIPS 140-3, tie the AES evidence to the validated cryptographic module boundary rather than to the surrounding application alone.

Sources for this answer:

- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search page for locating algorithm validation records such as AES implementation certificates.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Defines security requirements for cryptographic modules and separates module validation from the AES algorithm specification.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Explains that CMVP validates cryptographic modules and CAVP addresses testing of approved security functions referenced by FIPS 140-3.

*Recommended next step*

*Placement: after FAQ answers*

## Turn FIPS algorithm questions into verifiable evidence

Use the cited standards, CAVP records, CMVP certificate data, and Security Policy language to keep algorithm claims precise before they reach customers, auditors, or procurement teams.

- [Open Assessment Autopilot for FIPS evidence](/solutions/assessment.md): Convert FIPS algorithm and module evidence into owned tasks, evidence requests, and review checkpoints.
- [Research FIPS source questions](/solutions/research-copilot.md): Resolve CAVP, CMVP, approved-mode, and algorithm-standard questions against cited source material.
- [Review a FIPS claim with Sorena](/contact.md): Check whether customer-facing wording matches the underlying algorithm, module, and validation evidence.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/faq/items