We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

FAQGLOBALFIPS hash-function evidence

FIPS 180-4 and FIPS 202 hash functions How should teams use them in FIPS-approved algorithm decisions?

Use FIPS 180-4 to identify SHA-1 and SHA-2 and FIPS 202 to identify SHA-3 and SHAKE, then check the intended operation's current status and verify implementation and module evidence separately.

This FAQ separates hash-function selection from higher-level algorithm approval and cryptographic module validation.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
4 sections6 primary sources
Overview

Identify the exact or SHAKE function, cite FIPS 180-4 or FIPS 202 for its specification, check the current approved-use source for the intended operation, use evidence for the tested implementation, and use evidence for a FIPS 140-3 module claim.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

Which hash functions come from FIPS 180-4 and FIPS 202?

FIPS 180-4 is the current issued 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 is the current issued standard for the SHA-3 family: SHA3-224, SHA3-256, SHA3-384, and SHA3-512. It also specifies SHAKE128 and SHAKE256; each is an whose output length is selected by the application. NIST has announced plans to revise FIPS 180-4 and update FIPS 202, but those announcements do not replace the issued standards.

For a FIPS-approved algorithm decision, start by naming the exact function and use case. A message digest for digital signatures, an HMAC construction, a KDF, a DRBG, a post-quantum algorithm component, and a standalone SHAKE use can have different validation evidence even when the same hash family appears in the design.

SHA-1 needs a use-specific transition check. FIPS 180-4 still specifies SHA-1, but NIST transition guidance disallows SHA-1 for ordinary digital-signature generation while allowing legacy signature verification and some protocol-specific uses under stated conditions. Do not infer an approved current use from the fact that SHA-1 remains in the hash standard.

  • Use FIPS 180-4 to identify the SHA-1 or SHA-2 digest specification, but check the current approved-use source before treating a particular SHA-1 operation as approved.
  • 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.
Question 2

What evidence proves the hash implementation is approved?

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

Keep that algorithm evidence separate from the module evidence. validates algorithm implementations; validates cryptographic modules under FIPS 140-3. A module claim needs the module certificate, approved-mode documentation, and security policy scope, not only a hash-algorithm certificate.

  • Capture the algorithm name, certificate number or validation entry, implementation version, vendor, and tested operating environment.
  • For software modules, compare the 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 -facing documentation.
Recommended next step

Separate FIPS 180-4, FIPS 202, CAVP, and CMVP claims before review

This FAQ helps align hash-function selection, algorithm validation evidence, module scope, and approved-mode service documentation.

Assessment workflow
Check the evidence boundary

Review whether hash, higher-level algorithm, and module validation claims point to the right records.

Explore next step
Research workflow
Resolve a scoped FIPS question

Compare the applicable NIST standard, CAVP evidence, and CMVP evidence when a hash function is used inside a larger cryptographic claim.

Explore next step
Talk to Sorena
Talk through implementation

Review the product boundary, operating environment, and validation evidence for the hash functions in scope.

Explore next step
Question 3

Where do teams make mistakes with SHA-3 and SHAKE?

Do not treat 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. implementation guidance is more restrictive for SHAKE128 and SHAKE256: outside algorithm standards that explicitly allow them, SHAKE functions are used as standalone algorithms.

A second mistake is importing a hash certificate into a higher-level claim without checking whether the higher-level algorithm has its own testing requirement or vendor-affirmed path. That matters for signatures, KDFs, DRBGs, and module approved-service listings.

  • 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 certificate.
  • Do not reuse a hash validation across a changed implementation or operating environment without checking the certificate scope.
Question 4

Questions and answers

Which standard should I cite for SHA-1, SHA-2, SHA-3, and SHAKE?

Use FIPS 180-4 to identify SHA-1 and the SHA-2 family, and FIPS 202 to identify SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. A specification citation does not settle current approval for every use. In particular, SHA-1 is disallowed for ordinary digital-signature generation but remains usable for specified legacy verification and limited protocol cases, so check the current transition rule for the exact operation.

Does a hash certificate prove the whole product is FIPS validated?

No. A certificate supports the tested algorithm implementation only. A certificate is needed for a FIPS 140-3 cryptographic module claim.

What evidence should I keep with a hash-function claim?

Keep the exact algorithm name, implementation version, certificate or validation entry, vendor, tested operational environment, and the module or service scope that the evidence actually supports.

Primary sources

References and citations

NIST FIPS 202 SHA-3 Standard
csrc.nist.gov3 citations
Referenced sections
  • Identifies the SHA-3 hash functions and SHAKE extendable-output functions and records NIST's planned update and Appendix B correction.
  • Identifies the SHA-3 hash functions and SHAKE extendable-output functions and records NIST's planned update and non-normative Appendix B correction.
  • Explains that SHA-3 functions supplement FIPS 180-4 hash functions and that SHAKE output length is application-dependent.
"SHA3-224, SHA3-256, SHA3-384, and SHA3-512"
More quoted passages
"the length of the output can be chosen"
NIST Cryptographic Algorithm Validation Program
csrc.nist.gov2 citations
Referenced sections
  • Program source for CAVP algorithm implementation validation evidence.
  • Program source for checking whether an algorithm implementation has CAVP validation evidence.
"Cryptographic Algorithm Validation Program"
NIST Cryptographic Module Validation Program
csrc.nist.gov2 citations
Referenced sections
  • Program page for CMVP module validation, which is separate from CAVP algorithm implementation testing.
  • Supports keeping module validation status and approved-mode service claims separate from standalone hash-function selection.
"CMVP"
NIST FIPS 180-4 Secure Hash Standard
csrc.nist.gov2 citations
Referenced sections
  • Identifies the SHA-1 and SHA-2 algorithms in the current issued standard and records NIST's decision to revise it.
  • Identifies the SHA-1 and SHA-2 algorithms in the current issued Secure Hash Standard and records NIST's decision to revise it.
"SHA-1, SHA-224, SHA-256, SHA-384, SHA-512"
NIST SP 800-131A Rev. 2 cryptographic algorithm transitions
csrc.nist.gov2 citations
Referenced sections
  • Current transition guidance needed to determine whether a specific SHA-1 operation is approved, legacy-only, or disallowed.
  • Provides current-use transition treatment for SHA-1, including the distinction between digital-signature generation and legacy verification.

Related guides

FIPS 203, 204, and 205 Post-Quantum Algorithms

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.

FIPS Algorithm Procurement Evidence FAQ

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

FIPS validation certificates for cryptographic algorithms

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

How FIPS 186-5 Signature Algorithms Fit FIPS Approval

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

What does FIPS 197 AES mean for FIPS-approved algorithms?

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.

AES FIPS 197 requirements and evidence

AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.

Show all related guides (25)

CAVP Algorithm Validation and ACVP Testing

How CAVP algorithm validation, the ACVP protocol, the ACVTS test system, and CMVP module validation fit together without overstating a FIPS claim.

CAVP Validation Evidence Workflow for FIPS Algorithms

Workflow for collecting CAVP validation evidence and ACVP/ACVTS test records: implementation identity, tested parameters, environments, and CMVP handoff records.

FIPS 180-4 and FIPS 202 secure hash guidance

Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims.

FIPS 186-5 and FIPS 204 digital signatures

Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries.

FIPS 203 ML-KEM vs RSA and ECDH key establishment

Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP evidence.

FIPS approved algorithm selector workflow

A cited workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.

FIPS approved mode procurement: certificates, boundaries, and evidence

Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase.

FIPS crypto transition and deprecation tracker

Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status.

FIPS cryptographic algorithm selector

Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope.

FIPS KDF and MAC coverage for validated modules

Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries.

FIPS Key Management Mapping for Algorithms and SSP Evidence

Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records.

FIPS Procurement Evidence Review Workflow: CAVP, CMVP, Approved Mode

Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records.

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.

ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5

Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries.

Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA

An official source guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ.

Post-Quantum Migration for FIPS Cryptography

Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries.

Post-Quantum Migration Tracker for FIPS 203, 204, and 205

Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries.

SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202

Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required.

TLS use-case mapping for FIPS algorithm evidence

Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.