Artifact GuideGLOBALSecure hash evidence

FIPS 180-4 and FIPS 202 secure hash guidance

A practical guide for selecting SHA-2, SHA-3, or SHAKE functions and keeping the evidence clean for CAVP, ACVP, and FIPS 140-3 reviews.

Use it to separate algorithm conformance from module validation, protocol requirements, procurement wording, and internal migration policy.

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 hash from the consuming construction first. FIPS 180-4 currently specifies SHA-1 and the family; FIPS 202 specifies four hash functions and two extendable-output functions. These FIPS publications govern covered U.S. federal uses and are available for non-federal adoption, but a protocol, signature scheme, KDF, contract, or internal policy may impose the narrower choice. Record the exact function, digest or output length, protocol or construction, tested implementation, operational environment, and module boundary. A standardized hash name does not by itself prove that the implementation, product, protocol, or FIPS 140-3 service is validated.

Section 1

Start with the hash function family and use case

FIPS 180-4 specifies SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 specifies SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. The and suffixes identify fixed digest lengths. In SHAKE128 and SHAKE256, the suffix indicates the security strength the XOF can generally support; the caller still chooses the output length.

Record the consuming use case before selecting the primitive. A hash used inside a digital signature, HMAC, KDF, pseudorandom bit generator, firmware integrity mechanism, certificate profile, or protocol transcript inherits requirements from that higher-level standard. It may also require domain separation, a minimum output length, a specific algorithm revision, or different validation coverage. If the higher-level construction names one function, do not substitute another merely because both functions appear in a FIPS publication.

Use FIPS 180-4 when the requirement calls for or an existing SHA-1/SHA-2 interface that must be evidenced against the Secure Hash Standard.
Use FIPS 202 when the design needs family diversity, SHA3 fixed-length hashes, or output that is explicitly allowed by the consuming NIST publication or protocol.
Treat SHAKE128 and SHAKE256 as XOFs, not fixed-output hash-function drop-ins. Cite the higher-level NIST publication or protocol that permits the use and fixes the output length.
If SHA-1 remains in scope, document the operation, legacy dependency, controlling transition rule, and removal owner. NIST has decided that the future revision of FIPS 180-4 will remove SHA-1, but FIPS 180-4 remains the published standard until that revision is issued.

Sources for this answer

NIST FIPS 180-4 Secure Hash Standard

Identifies the SHA-1 and SHA-2 algorithms covered by the Secure Hash Standard.

NIST FIPS 202 SHA-3 Standard

Identifies SHA-3 hash functions and SHAKE extendable-output functions.

NIST decision to revise FIPS 180-4

States that NIST decided to revise FIPS 180-4 and remove the SHA-1 specification; the announcement is a revision decision, not the revised standard.

Section 2

Keep algorithm validation separate from module validation

For assurance and procurement, split the claim into two layers. The public entry can support the tested hash implementation, while ACVP and ACVTS artifacts are supporting test records. The cryptographic module that exposes the service is validated separately by against FIPS 140-3. An algorithm certificate does not prove that the product, module boundary, operational environment, or approved mode is validated.

The evidence package should name the algorithm certificate, implementation version, tested operational environment, module certificate, approved service, and the exact product build that consumes the hash. If the algorithm implementation changes during integration, or if the operational environment differs from the tested environment, the existing algorithm evidence may not carry forward without retesting or validation review.

Record the public validation entry for the actual , , or implementation and parameter set; link any internal ACVP/ACVTS test records separately.
Record evidence separately for the FIPS 140-3 module, including certificate number, module version, tested operating environment, approved mode, and Security Policy reference.
Check whether the hash operation is provided by the module itself, a bound module, or an embedded validated module, because the boundary changes what can be claimed.
Do not write procurement language that says a product is FIPS validated when only an algorithm implementation has been tested.

Sources for this answer

NIST CAVP validation search

Supports distinguishing CAVP algorithm records from CMVP module certificates and tested operational environments.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports FIPS 140-3 as the module-security standard, not a standalone hash algorithm certificate.

Section 3

Decision checklist for SHA-2, SHA-3, and SHAKE

The consuming standard and required security strength usually control the choice. SHA-256 and SHA-384 commonly appear because protocols and signature schemes specify them. offers a Keccak-based design that differs from , but FIPS 202 does not make it a mandatory replacement. is appropriate only when the construction permits an XOF and fixes an output length that meets its security target. If no controlling construction permits the proposed function, stop the selection and record the design gap rather than treating a standalone FIPS citation as approval.

Write the decision record so a reviewer can reproduce the reasoning without hidden context. The record should state the function name, digest or output length, input domain, consuming construction, security-strength target, validation evidence, and migration trigger.

For digital signatures, record the signature standard or certificate profile that constrains the hash choice and digest length.
For HMAC, record the selected hash function and confirm whether the consuming implementation has the required validation evidence.
For KDF or pseudorandom bit generation use, cite the higher-level NIST publication or protocol that permits the selected , , or construction.
For file, firmware, or software checks, distinguish accidental-change detection from authenticity. A bare digest can detect a mismatch only when the expected digest is itself trusted; use the required signature, MAC, or approved integrity technique when an attacker could replace both the file and digest.

Sources for this answer

NIST FIPS 180-4 Secure Hash Standard

Supports SHA-2 family digest lengths and the use of secure hashes with signatures, MACs, and random bit generation.

NIST FIPS 202 SHA-3 Standard

Supports SHA-3 as a supplement to SHA-1 and SHA-2, and SHAKE as an extendable-output function.

Recommended next step

Operationalize FIPS 180-4 and FIPS 202 decisions

Use the hash selection, validation, module-boundary, and change-control notes as a shared evidence checklist before publishing a FIPS claim.

Assessment workflow

Open Assessment Autopilot for FIPS hash evidence

Convert SHA-2, SHA-3, and SHAKE decisions into accountable evidence tasks and review checkpoints.

Explore next step

Research workflow

Research FIPS source questions

Resolve hash-family, CAVP, ACVP, and FIPS 140-3 boundary questions before implementation.

Explore next step

Talk to Sorena

Talk through FIPS hash implementation

Review the selected hash functions, validation evidence, module boundaries, and change triggers with Sorena.

Explore next step

Section 4

Evidence to keep with the implementation

A useful hash evidence pack is more than a source citation. It should connect the standard to the actual implementation, validation certificate, module boundary, service name, and change-control record. This is what prevents an auditor or customer from having to guess whether the hash claim applies to the shipped build.

For FIPS 140-3 contexts, the evidence should also show whether the service runs in approved mode and whether the module Security Policy lists the hash algorithm or integrity mechanism in the relevant service table. If the hash comes through a bound or embedded module, keep the referenced module name, certificate number, version, and used functionality explicit.

Algorithm evidence: public validation identifier, implementation name and version, tested operating environment, algorithm mode or parameter set, and any linked internal ACVP/ACVTS test records.
Module evidence: certificate, module version, Security Policy, approved-service mapping, and operational environment.
Design evidence: why , , or was selected, which output length is used, and which consuming protocol or construction requires it.
Change evidence: trigger retesting or review when the hash implementation, compiler, processor, operating environment, cryptographic boundary, digest or XOF output length, consuming construction, certificate profile, or protocol changes.

Sources for this answer

NIST CAVP validation search

Supports evidence requirements for algorithm certificate binding, implementation version, and operational environment.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports approved security functions and the module-level assurance boundary.

Section 5

Common mistakes in secure hash claims

Hash claims often fail because the evidence covers a narrower object than the wording. Name the function, construction, implementation, environment, and module service instead of expanding an algorithm citation into a product claim.

Do not say is a mandatory replacement for . FIPS 202 says SHA-3 supplements the FIPS 180-4 hash functions and provides design diversity.
Do not call SHAKE128 or SHAKE256 a hash function in approval language. Treat them as XOFs and cite the higher-level rule that permits the intended use.
Do not use a certificate from one operating environment to support a different module environment without checking the FIPS 140-3 binding rules.
Do not hide SHA-1 behind a generic Secure Hash Standard reference; name the function and the legacy or protocol reason it remains present.
Do not imply that hashing alone provides authenticity. Pair integrity claims with the signature, MAC, approved integrity technique, or module service that actually provides the assurance.