--- title: "SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3" author: "Sorena AI" description: "Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "SHA-2 vs SHA-3" - "FIPS 180-4" - "FIPS 202" - "SHA-256" - "SHA3-256" - "SHAKE" - "CAVP validation" - "FIPS hash algorithms" - "SHA-2" - "SHA-3" --- **[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) --- # 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. *Artifact Guide* *GLOBAL* *FIPS Hash Algorithms* ## SHA-2 vs SHA-3 under FIPS A grounded 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. SHA-2 and SHA-3 are both NIST-standardized hash families, but they are not interchangeable labels. FIPS 180-4 defines SHA-1 and the SHA-2 family, while FIPS 202 defines SHA-3 hash functions and SHAKE extendable-output functions. For real programs, the decision is usually less about which family is newer and more about which function the protocol, product boundary, customer requirement, or validation evidence actually supports. ## FIPS 180-4 SHA-2 vs FIPS 202 SHA-3: what changes operationally? Use this comparison to decide whether the work is algorithm selection, validation evidence, protocol compatibility, procurement wording, or FIPS 140-3 module assurance. - **FIPS 180-4 SHA-2**: 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. - **FIPS 202 SHA-3**: 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 | Sources | | --- | --- | --- | --- | --- | | 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. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Explains that SHAKE output can be extended to a desired length, making output length part of the claim. | | Covered actors | Federal agencies, contractors, and cryptographic module vendors selecting SHA-2 family functions under FIPS 180-4 for digital signatures, HMACs, key derivation, or other secure-hash use cases requiring NIST-approved algorithms. | Federal agencies, contractors, and module vendors selecting SHA-3 or SHAKE functions under FIPS 202 for designs where a SHA-3 or extendable-output function is required by a protocol, procurement specification, or NIST guidance document. | Map the actor role to the algorithm family: SHA-2 actors satisfy FIPS 180-4; SHA-3/SHAKE actors satisfy FIPS 202; both may appear in the same module. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | | 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 SHAKE 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. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by 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 the same secure-hash requirement when a SHA-3 or SHAKE function is appropriate. | Confirm that the selected function is approved for the use case; SHA-2 and SHA-3 are both approved but interoperability constraints may limit substitution. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | | 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 SHAKE implementation claim should point to CAVP validation evidence for the tested function implementation, not only to FIPS 202. | Point to the CAVP validation record for the specific function and implementation; SHA-2 and SHA-3 records are separate and cannot be reused across families. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | | 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. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | | Enforcement | A SHA-2 CAVP validation confirms that the specific SHA-224, SHA-256, SHA-384, or SHA-512 implementation produces correct outputs for the tested function. For a FIPS 140-3 module claim, the module security policy must name the validated SHA-2 function, the implementation must sit inside the defined cryptographic boundary, and the module certificate must list the algorithm under approved services. | A SHA-3 or SHAKE CAVP validation covers the specific SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, or SHAKE256 implementation tested. For a FIPS 140-3 module claim using SHAKE, the module security policy must specify the output length constraints, because FIPS 202 CAVP entries are separate from FIPS 180-4 entries and cannot be substituted for each other in the module certificate's approved algorithm list. | Check that the CAVP validation covers the specific function, variant, and operating mode being claimed; SHA-2 and SHA-3 validation entries are not interchangeable. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | | Overlap | SHA-2 and SHA-3 are both NIST-approved secure-hash algorithm families, both listed in SP 800-57 key-management guidance, and both subject to CAVP validation requirements for federal cryptographic modules. | Algorithm validation for SHA-2 and SHA-3 uses the same CAVP submission process and does not, by itself, constitute a FIPS 140-3 module validation. Procurement evidence for either family should distinguish algorithm validation records from module validation certificates. | Treat SP 800-131A algorithm status and CAVP submission process as shared controls; both SHA-2 and SHA-3 follow the same validation framework. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | | 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 SHAKE, 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 operating mode for either family; SHAKE output length is an additional required field for SHA-3. | [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4.
[NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. | Sources for Function scope - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. - Quote: "SHA-224, SHA-256, SHA-384, SHA-512" Sources for Function scope - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. - Quote: "SHAKE128 and SHAKE256" Sources for Function scope - operational implication: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Explains that SHAKE output can be extended to a desired length, making output length part of the claim. - Quote: "the output can be extended to any desired length" Sources for Covered actors - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Covered actors - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Covered actors - operational implication: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Trigger - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Trigger - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Trigger - operational implication: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Core obligations - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Core obligations - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Core obligations - operational implication: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Evidence - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Evidence - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Evidence - operational implication: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Timing - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Timing - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Timing - operational implication: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Enforcement - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Enforcement - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Enforcement - operational implication: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Overlap - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Overlap - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Overlap - operational implication: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Decision rule - FIPS 180-4 SHA-2: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. Sources for Decision rule - FIPS 202 SHA-3: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. Sources for Decision rule - operational implication: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. ### Which hash standard to apply - Use FIPS 180-4 SHA-2 when the protocol, certificate ecosystem, signature scheme, or procurement specification already relies on SHA-2 and the current NIST approval status is confirmed. - Use FIPS 202 SHA-3 or SHAKE when the design, protocol, or NIST guidance explicitly requires a SHA-3 or extendable-output function and the implementation has a matching CAVP validation entry. - Do not migrate from SHA-2 to SHA-3 solely to modernize a label if the surrounding protocol, certificate, or module dependencies do not support the change. - Review the hash function choice after SP 800-131A revisions, module recertification cycles, or protocol updates that change the approved algorithm status for either family. ## Use SHA-2 vs SHA-3 as a scope and evidence decision 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 mean every SHA-2 deployment should be replaced by SHA-3. It means the team must use an approved hash function that fits the surrounding standard, protocol, validation, and assurance claim. - Use SHA-2 when the controlling protocol, certificate profile, signature scheme, KDF, or customer requirement names a FIPS 180-4 function. - Use SHA-3 or SHAKE when the controlling design, standard, or assurance case specifically calls for FIPS 202 functions. - Avoid rewriting a working SHA-2 design solely because SHA-3 exists; first check interoperability, validation coverage, and the actual relying standard. - Record the exact algorithm name and output length in procurement and evidence files so a reviewer does not infer unsupported coverage. Sources for this answer: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Defines the SHA-1 and SHA-2 secure hash algorithms and states where FIPS 180-4 or FIPS 202 applies. - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Defines the SHA-3 hash functions and SHAKE extendable-output functions. *Recommended next step* *Placement: after practical guidance* ## Operationalize hash selection evidence Use this comparison to turn hash choices into validation checks, procurement questions, and release-review evidence instead of broad FIPS claims. - [Open Assessment Autopilot for FIPS hash evidence](/solutions/assessment.md): Convert SHA-2 and SHA-3 decisions into accountable evidence requests, validation checks, and review milestones. - [Research FIPS source questions](/solutions/research-copilot.md): Use cited source material to resolve algorithm, validation, procurement, and module-boundary questions before implementation. - [Talk through implementation](/contact.md): Review scope, evidence, owners, and the next cryptographic assurance actions with Sorena. ## Do not confuse algorithm approval with module validation 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 CAVP or ACVP algorithm validation details and, where a product makes a FIPS 140-3 claim, the CMVP module certificate and Security Policy. The useful evidence links the exact implementation and operational environment to the hash function being claimed. - Ask vendors for the algorithm certificate or validation entry for the specific hash implementation, not only a standards citation. - Ask whether the hash function is inside the validated cryptographic module boundary and approved mode when the claim depends on FIPS 140-3. - Treat a module certificate, algorithm validation, protocol conformance statement, and procurement answer as separate evidence items. - Recheck evidence after library, firmware, operating environment, module boundary, or service configuration changes. Sources for this answer: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - States that only NIST-validated algorithm implementations are considered compliant with the standard. - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - States that SHA-3 function implementations must be validated by CAVP for compliance with FIPS 202. - [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 the difference between CAVP algorithm validation and CMVP module validation evidence. ## Compare compatibility before planning a migration 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. A SHA-3 migration is stronger when it is tied to a new architecture, a specific standard that supports it, or a validated implementation already available in the product boundary. - Check whether the consuming protocol permits the target SHA-3 or SHAKE function before changing code. - Check whether vendors can provide current validation evidence for the exact implementation and operational environment. - Keep SHAKE decisions explicit because SHAKE128 and SHAKE256 are extendable-output functions, not fixed-length SHA3-128 or SHA3-256 aliases. - Document why SHA-2 remains acceptable when interoperability, validation, or customer requirements still depend on it. Sources for this answer: - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Explains that SHA-3 supplements SHA-2 and can be used as an alternative where the surrounding design allows it. - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Defines SHAKE128 and SHAKE256 as extendable-output functions whose output length is selected by the use case. ## Procurement questions that prevent overclaims Procurement language should ask for the evidence behind the claim, not just whether a supplier uses SHA-2 or SHA-3. 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 source-linked standard and implementation-specific validation evidence. - Which exact hash functions are used: SHA-256, SHA-384, SHA-512/256, SHA3-256, SHA3-384, SHAKE128, or SHAKE256? - Is the algorithm implementation validated, and what certificate or validation entry identifies it? - Is the hash used inside a FIPS 140-3 validated module boundary, and is the claimed service available in approved mode? - Which protocol, certificate profile, signature scheme, KDF, MAC, or internal design decision requires this hash choice? - What changes would require updated evidence: library version, firmware, operating environment, module boundary, protocol profile, or output length? Sources for this answer: - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search entry point for checking algorithm validation records used in procurement evidence. - [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) - Grounds the need to track algorithm and module validation evidence separately. ## Review checklist for SHA-2 and SHA-3 evidence Use this checklist when a design review, customer answer, supplier review, or audit file depends on SHA-2 vs SHA-3. The goal is a record that stands on its own without asking a later reviewer to reconstruct the cryptographic boundary from memory. - Name the exact FIPS source: FIPS 180-4 for SHA-2 functions, FIPS 202 for SHA-3 and SHAKE functions. - Name the exact function and output length used by each product, protocol, certificate profile, or service. - Attach CAVP or ACVP evidence for the tested implementation when an implementation compliance claim is made. - Attach CMVP module evidence when the public claim depends on a FIPS 140-3 validated module or approved mode. - Record when SHA-2 is retained because the surrounding protocol, certificate ecosystem, customer requirement, or validation path controls the choice. - Record when SHA-3 or SHAKE is adopted because the surrounding standard, design, or validation path actually supports it. Sources for this answer: - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Primary source for SHA-2 family names and FIPS 180-4 applicability. - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Primary source for SHA-3 and SHAKE family names and FIPS 202 applicability. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary source for FIPS 140-3 module-validation framing when hash functions are used inside a cryptographic module. ## Primary sources - [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Lists the SHA-2 functions covered by FIPS 180-4. - [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Lists the SHA-3 hash functions and SHAKE XOFs covered by FIPS 202. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search entry point for checking implementation-specific algorithm validation evidence. - Quote: "validation-search" - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary source for module-validation framing when hash functions are part of a FIPS 140-3 claim. - Quote: "Security Requirements for Cryptographic Modules" - [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) - Grounds the practical separation between CAVP algorithm validation and CMVP module validation evidence. - Quote: "algorithm validation certificate states the name and version number" ## Related Topic Guides - [AES FIPS 197 requirements and evidence](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims. - [CAVP and ACVP validation evidence for FIPS algorithms](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim. - [CAVP Validation Evidence Workflow for FIPS Algorithms](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records. - [FIPS 180-4 and FIPS 202 secure hash guidance](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): 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](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): 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](/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh.md): Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding. - [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. - [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. - [FIPS approved algorithm selector workflow](/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow.md): A source-linked 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](/artifacts/global/fips-crypto-algorithms/approved-mode-procurement.md): 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](/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker.md): 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](/artifacts/global/fips-crypto-algorithms/algorithm-selector.md): 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](/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage.md): 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](/artifacts/global/fips-crypto-algorithms/key-management-mapping.md): 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](/artifacts/global/fips-crypto-algorithms/procurement-evidence-review-workflow.md): 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 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. - [FIPS-approved cryptographic algorithms FAQ](/artifacts/global/fips-crypto-algorithms/faq.md): 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. - [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. - [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. - [ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5](/artifacts/global/fips-crypto-algorithms/ml-dsa-vs-ecdsa.md): 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](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): A grounded 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](/artifacts/global/fips-crypto-algorithms/post-quantum-migration.md): 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](/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker.md): 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. - [TLS use-case mapping for FIPS algorithm evidence](/artifacts/global/fips-crypto-algorithms/tls-use-case-mapping.md): Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims. - [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. --- [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/sha-2-vs-sha-3