A cited-source comparison for choosing, procuring, and evidencing SHA-2 and SHA-3 hash functions in FIPS-sensitive systems.
Use it to separate algorithm approval, CAVP evidence, protocol compatibility, and FIPS 140-3 module claims.
Structured answer sets in this page tree.
Cited legal and guidance references.
Keep SHA-2 when the protocol, certificate profile, signature scheme, validated module, or customer requirement names a SHA-2 function. Use SHA-3 when the surrounding design permits the corresponding FIPS 202 hash, or when an approved use needs variable-length output. The families use different internal constructions, but SHA3-256 does not automatically provide more than SHA-256. Record the exact function, output length, purpose, implementation, evidence, and FIPS 140-3 module boundary.
This comparison helps decide whether the work is algorithm selection, validation evidence, protocol compatibility, procurement wording, or FIPS 140-3 module assurance.
Use FIPS 180-4 for SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256 decisions, while handling SHA-1 as a legacy-sensitive case.
Use FIPS 202 for SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256 decisions.
| Dimension | FIPS 180-4 SHA-2 | FIPS 202 SHA-3 | Operational implication |
|---|---|---|---|
| Function scope | FIPS 180-4 defines SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. | FIPS 202 defines SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus SHAKE128 and SHAKE256 extendable-output functions. | Do not compare only the family names. Record the exact function and output length before making a design, validation, or procurement claim. |
| Covered actors | FIPS 180-4 applies to federal applications that select one of its secure hash algorithms, including systems operated for agencies under contract. Private and commercial organizations may also adopt it. | FIPS 202 applies to federal applications that select SHA-3, while uses must also follow the NIST publication that approves the particular XOF use. Private and commercial organizations may adopt these functions. | The actor's role does not select the function. The application, protocol, approved use, validation record, and system requirement do. |
| Trigger | SHA-2 is still common where TLS profiles, digital signatures, certificate ecosystems, firmware tooling, or customer controls name SHA-256 or SHA-384. | SHA-3 or fits better where a new design, protocol, or standard explicitly allows FIPS 202 functions and validated implementations are available. | Use SHA-2 where protocol profiles, certificate ecosystems, or firmware require it; switch to SHA-3 only when the standard or design explicitly allows FIPS 202. |
| Core obligations | FIPS 180-4 can satisfy the secure-hash requirement for Federal applications when a FIPS 180-4 function is the appropriate function. | FIPS 202 can satisfy a secure-hash requirement with SHA-3 when that fixed-output function is appropriate. is an XOF, not an approved hash function, and its approved uses are specified separately by NIST. | Confirm the exact operation and approved use. SHA-2 and SHA-3 fixed-output hashes can both satisfy secure-hash requirements, but needs use-specific approval and all substitutions remain subject to interoperability constraints. |
| Evidence | A SHA-2 implementation claim should point to NIST validation evidence for the tested implementation, not only to FIPS 180-4. | A SHA-3 or implementation claim should point to validation evidence for the tested function implementation, not only to FIPS 202. | Point to the validation record for the specific function and implementation; SHA-2 and SHA-3 records are separate and cannot be reused across families. |
| Timing | Keep SHA-2 when it is approved for the use case, supported by current validation evidence, and required by the protocol or customer environment. | Do not switch to SHA-3 just to modernize a label if the surrounding protocol, certificate profile, module certificate, or customer requirement does not support it. | Keep the existing algorithm if it is approved, validated, and supported by the current protocol profile; do not modernize labels without functional justification. |
| Enforcement | A SHA-2 validation confirms that the specific SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 implementation produces correct outputs for the tested function. For a FIPS 140-3 module claim, the implementation must be inside the defined cryptographic boundary, the algorithm implementation must be listed as an approved security function on the module certificate, and the Security Policy must document the relevant approved service. | A SHA-3 or validation covers the specific SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, or SHAKE256 implementation tested. For use in a FIPS 140-3 module's approved mode, each implemented SHA-3 or SHAKE function must be CAVP tested and validated on all of the module's operating environments; outside standards that explicitly permit another use, SHAKE128 and SHAKE256 may only be used as standalone algorithms. | Check that the validation covers the specific function, capabilities, and operational environment being claimed; SHA-2 and SHA-3 validation entries are not interchangeable. |
| Overlap | SHA-2 and SHA-3 are both NIST-approved secure-hash algorithm families and both are subject to validation requirements when used as approved hash algorithms in federal cryptographic modules. | Algorithm implementations for SHA-2 and SHA-3 are tested and validated under , but algorithm validation does not, by itself, constitute FIPS 140-3 module validation. Procurement evidence for either family should distinguish algorithm validation records from module validation certificates. | Check the current NIST status for the exact hash operation, and keep the algorithm-validation record separate from any CMVP module claim for both families. |
| Decision rule | For SHA-2, ask for the exact function, implementation version, validation entry, operating environment, and any FIPS 140-3 module boundary that uses it. | For SHA-3 or , ask the same questions and include the selected SHAKE output length if an XOF is used. | Ask for the exact function, implementation version, validation entry, and operational environment for either family; output length is an additional required field when SHAKE is used. |
FIPS 180-4 defines SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.
FIPS 202 defines SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus SHAKE128 and SHAKE256 extendable-output functions.
Do not compare only the family names. Record the exact function and output length before making a design, validation, or procurement claim.
FIPS 180-4 applies to federal applications that select one of its secure hash algorithms, including systems operated for agencies under contract. Private and commercial organizations may also adopt it.
FIPS 202 applies to federal applications that select SHA-3, while uses must also follow the NIST publication that approves the particular XOF use. Private and commercial organizations may adopt these functions.
The actor's role does not select the function. The application, protocol, approved use, validation record, and system requirement do.
SHA-2 is still common where TLS profiles, digital signatures, certificate ecosystems, firmware tooling, or customer controls name SHA-256 or SHA-384.
SHA-3 or fits better where a new design, protocol, or standard explicitly allows FIPS 202 functions and validated implementations are available.
Use SHA-2 where protocol profiles, certificate ecosystems, or firmware require it; switch to SHA-3 only when the standard or design explicitly allows FIPS 202.
FIPS 180-4 can satisfy the secure-hash requirement for Federal applications when a FIPS 180-4 function is the appropriate function.
FIPS 202 can satisfy a secure-hash requirement with SHA-3 when that fixed-output function is appropriate. is an XOF, not an approved hash function, and its approved uses are specified separately by NIST.
Confirm the exact operation and approved use. SHA-2 and SHA-3 fixed-output hashes can both satisfy secure-hash requirements, but needs use-specific approval and all substitutions remain subject to interoperability constraints.
A SHA-2 implementation claim should point to NIST validation evidence for the tested implementation, not only to FIPS 180-4.
A SHA-3 or implementation claim should point to validation evidence for the tested function implementation, not only to FIPS 202.
Point to the validation record for the specific function and implementation; SHA-2 and SHA-3 records are separate and cannot be reused across families.
Keep SHA-2 when it is approved for the use case, supported by current validation evidence, and required by the protocol or customer environment.
Do not switch to SHA-3 just to modernize a label if the surrounding protocol, certificate profile, module certificate, or customer requirement does not support it.
Keep the existing algorithm if it is approved, validated, and supported by the current protocol profile; do not modernize labels without functional justification.
A SHA-2 validation confirms that the specific SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 implementation produces correct outputs for the tested function. For a FIPS 140-3 module claim, the implementation must be inside the defined cryptographic boundary, the algorithm implementation must be listed as an approved security function on the module certificate, and the Security Policy must document the relevant approved service.
A SHA-3 or validation covers the specific SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, or SHAKE256 implementation tested. For use in a FIPS 140-3 module's approved mode, each implemented SHA-3 or SHAKE function must be CAVP tested and validated on all of the module's operating environments; outside standards that explicitly permit another use, SHAKE128 and SHAKE256 may only be used as standalone algorithms.
Check that the validation covers the specific function, capabilities, and operational environment being claimed; SHA-2 and SHA-3 validation entries are not interchangeable.
SHA-2 and SHA-3 are both NIST-approved secure-hash algorithm families and both are subject to validation requirements when used as approved hash algorithms in federal cryptographic modules.
Algorithm implementations for SHA-2 and SHA-3 are tested and validated under , but algorithm validation does not, by itself, constitute FIPS 140-3 module validation. Procurement evidence for either family should distinguish algorithm validation records from module validation certificates.
Check the current NIST status for the exact hash operation, and keep the algorithm-validation record separate from any CMVP module claim for both families.
For SHA-2, ask for the exact function, implementation version, validation entry, operating environment, and any FIPS 140-3 module boundary that uses it.
For SHA-3 or , ask the same questions and include the selected SHAKE output length if an XOF is used.
Ask for the exact function, implementation version, validation entry, and operational environment for either family; output length is an additional required field when SHAKE is used.
Start by naming the exact function: SHA-256 is not the same claim as SHA-512/256, SHA3-256, or SHAKE256 with a chosen output length. The hash family, output length, implementation version, operational environment, and consuming protocol all affect the evidence a reviewer can rely on.
FIPS 180-4 says either FIPS 180-4 or FIPS 202 must be implemented wherever a secure hash algorithm is required for Federal applications. That does not require every SHA-2 deployment to move to SHA-3. The selected function must be approved for its particular use and fit the surrounding standard, protocol, validation, and assurance claim.
SHA-2 uses the iterative structure specified in FIPS 180-4, while SHA-3 uses KECCAK's sponge construction. Corresponding fixed-output pairs have the same generic collision strengths in FIPS 202: 112 bits for 224-bit digests, 128 for 256-bit digests, 192 for 384-bit digests, and 256 for 512-bit digests. SHA-3 also has resistance to length-extension attacks expected from a random function of the same output length, but that property alone does not make it a protocol-compatible substitute.
This comparison helps turn hash choices into validation checks, procurement questions, and release-review evidence instead of broad FIPS claims.
Convert SHA-2 and SHA-3 decisions into accountable evidence requests, validation checks, and review milestones.
Use cited source material to resolve algorithm, validation, procurement, and module-boundary questions before implementation.
Review scope, evidence, owners, and the next cryptographic assurance actions with Sorena.
A FIPS 180-4 or FIPS 202 citation supports the algorithm family and function definition. It does not by itself prove that a product, library, cloud service, HSM, firmware image, or software module is validated for a buyer's configuration.
For implementation evidence, look for the public validation entry and treat any ACVP/ACVTS session material as supporting test records. Where a product makes a FIPS 140-3 claim, check the CMVP module certificate and Security Policy separately. The useful evidence links the exact implementation and operational environment to the hash function being claimed.
SHA-3 supplements SHA-2; it is not a universal drop-in replacement for every deployed use. FIPS 202 says SHA-3 hash functions can be alternatives to SHA-2 functions, but the surrounding protocol or certificate profile still decides whether that alternative is allowed.
For many deployed systems, SHA-256 or SHA-384 remains the practical answer because TLS profiles, signature formats, certificate ecosystems, firmware update tooling, or customer controls already specify those functions. Adopt SHA-3 when a specific architecture or standard supports it and the product boundary has a validated implementation.
For SHAKE128 with d output bits, collision strength is min(d/2, 128) and preimage strength is at least min(d, 128); SHAKE256 uses a 256-bit ceiling. Longer output is an extension of shorter output for the same message, so protocols must bind the chosen output length and purpose rather than treating length as an incidental formatting choice.
Procurement language should require the evidence behind a SHA-2 or SHA-3 claim. A useful answer names the hash function, implementation, version, operating environment, validation reference, module boundary, approved-mode status, and any protocol that constrains the choice.
Be especially careful with broad statements such as "FIPS compliant hashing" or "SHA-3 ready." Those phrases are not enough for audit or customer assurance unless they are tied to a cited standard and implementation-specific validation evidence.
Use this checklist when a design review, customer answer, supplier review, or audit file depends on SHA-2 vs SHA-3. The resulting record should let a later reviewer identify the cryptographic boundary without reconstructing it from memory.
"validation-search"
"Security Requirements for Cryptographic Modules"