The Post-Quantum Field Guide

LaMarr LabsLaMarr Labs

SHA-2 vs SHA-3

13 min read

up:: Classical Cryptography MOC

SHA-2 vs SHA-3

SHA-2 and SHA-3 do the same job through entirely different machinery. SHA-2 chains a compression function over message blocks using the Merkle-Damgård construction. SHA-3 absorbs the whole message into one large permuted state and squeezes output back out, using the Keccak sponge.

Both are NIST-approved, neither is broken, and both survive the quantum transition on identical terms. NIST published SHA-3 to supplement SHA-2 rather than to supersede it, which means there is no forced migration between them and the choice is an engineering-fit question.

The short version:

  • The constructions are unrelated by design. SHA-2 uses Merkle-Damgård chaining and SHA-3 uses the Keccak sponge, so a break in one construction leaves the other family untouched. That independence is the reason NIST wanted both.
  • SHA-3 closes the length-extension property by design. A bare Merkle-Damgård hash lets someone who knows hash(secret || message) and the secret’s length compute hash(secret || message || extra), which is why SHA-2 needs the HMAC wrapper to authenticate messages safely.
  • Only SHA-3 ships extendable-output functions. SHAKE128 and SHAKE256 produce any output length from a single call, which is why post-quantum algorithms lean on them as a pseudorandom bit source.
  • Their quantum posture is identical. Grover’s halves preimage strength in both, collision resistance is barely touched in both because the birthday bound already sat there, and Shor’s applies to neither.
  • SHA-2 is not deprecated and SHA-3 is not a rescue. CNSA 2.0 keeps hashing inside the SHA-2 family, requires SHA-384 or SHA-512 for national-security work at all classification levels, and declines to approve SHA-3 or SHAKE as a general-purpose hash.

Two ways to reduce a long document to a short fingerprint. The first feeds the pages through a machine one at a time, carrying a running summary forward, so the machine’s internal state at the end is exactly what it hands you. The second drops the whole document into a tank, stirs it thoroughly, and pours off a sample, keeping most of the tank’s contents permanently out of the glass. Both produce a reliable fingerprint. Only the second makes it impossible to work out what was in the tank from the sample you were given, which turns out to matter for one specific trick.

What is the difference between SHA-2 and SHA-3?

The difference is the internal construction, and two practical consequences follow from it. SHA-2 is a Merkle-Damgård hash, which chains a compression function across message blocks and carries a chaining value forward, so the final internal state is the digest. SHA-3 is a sponge, which absorbs the message into a large state and squeezes the output from part of it, keeping the capacity bits permanently hidden.

Because the capacity bits never appear in the output, an attacker cannot reconstruct the internal state from a SHA-3 digest, which closes the length-extension property that bare SHA-2 has. The sponge also supports variable-length output naturally, which is where the SHAKE functions come from.

What is SHA-2?

SHA-2 is the family of hash functions defined in FIPS 180-4, standardized in 2002 and revised in 2015, built on the Merkle-Damgård construction. It has six members across two word-size branches:

MemberBranchOutput sizeEffective quantum preimage strengthEffective collision strength
SHA-22432-bit224-bit~112-bit~112-bit
SHA-25632-bit256-bit~128-bit~128-bit
SHA-38464-bit384-bit~192-bit~192-bit
SHA-51264-bit512-bit~256-bit~256-bit
SHA-512/22464-bit224-bit~112-bit~112-bit
SHA-512/25664-bit256-bit~128-bit~128-bit

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov.

What is SHA-3?

SHA-3 is the family defined in FIPS 202, standardized in 2015, built on the Keccak sponge construction. It provides four fixed-output members, SHA3-224, SHA3-256, SHA3-384 and SHA3-512, plus two extendable-output functions, SHAKE128 and SHAKE256, which have no equivalent in the SHA-2 standard.

It exists because of a competition NIST launched in 2007 as insurance. Related hash functions in the SHA-1 lineage were falling to new collision techniques at the time, and NIST wanted a structurally different backup ready in case SHA-2 followed. SHA-2 held up, so SHA-3 arrived as a strong sibling rather than a rescue.

Source: NIST, “SHA-3 Standard, Permutation-Based Hash and Extendable-Output Functions,” FIPS 202, August 2015, csrc.nist.gov.

SHA-2 vs SHA-3 at a glance

DimensionSHA-2SHA-3
StandardFIPS 180-4FIPS 202
Standardized2002, revised 20152015
Internal constructionMerkle-Damgård chainingKeccak sponge
Fixed-output membersSHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256SHA3-224, SHA3-256, SHA3-384, SHA3-512
Extendable outputNot in the standardSHAKE128, SHAKE256
Length-extension propertyPresent in bare use, closed by HMACClosed by the sponge design
Why it was createdThe successor family to SHA-1A structurally independent backup, from a competition launched in 2007
Quantum preimage strengthAbout half the output size under GroverAbout half the output size under Grover
Quantum collision strengthBarely affected, since the classical birthday bound already sat near half the outputThe same
Affected by Shor’sNo. There is no number-theoretic structure to attackNo
CNSA 2.0 positionRetained. SHA-384 or SHA-512 required for national-security work at all classification levelsNot approved as a general-purpose hash. SHA3-384 and SHA3-512 are allowed only for internal hardware functionality such as boot-up integrity checks
Hardware accelerationWidespread, including dedicated CPU instructionsLess widespread
Deployment breadthThe overwhelming default across TLS, PKI, code signing and package integrityGrowing, especially inside new protocol designs
Role in post-quantum algorithmsUsed, including as a building block in SLH-DSASHAKE is used heavily as a pseudorandom bit source in the new standards
NIST statusApprovedApproved alternative, supplementing rather than superseding

How do they actually differ?

  1. The independence is the point rather than a side effect. NIST ran the SHA-3 competition specifically to obtain a hash built on different mathematics, so that a cryptanalytic advance against Merkle-Damgård would leave a standardized alternative untouched. That reasoning parallels why a non-lattice post-quantum KEM was standardized alongside the lattice default.

  2. Length extension is a real property with a real workaround. Someone who knows hash(secret || message) and the length of the secret can compute hash(secret || message || extra) against a bare Merkle-Damgård hash without knowing the secret. HMAC closes this for SHA-2, which is why HMAC exists and why bare SHA-2 should never be used as a message authenticator. SHA-3 closes it in the construction, so it can be used more directly in some designs.

  3. Extendable output is a capability rather than a security difference. A single SHAKE call produces any requested output length, which suits key derivation, mask generation and the pseudorandom bit expansion that post-quantum schemes need constantly. Producing variable-length output from SHA-2 requires a construction wrapped around it.

  4. Performance runs the other way in most deployments. SHA-2 has had two decades of hardware acceleration, including dedicated CPU instructions, so it is frequently faster in practice despite SHA-3’s newer design. That gap is a deployment reality rather than a property of either algorithm.

  5. Their member sets are sized differently. SHA-2 offers six members across two word-size branches, including truncated variants that exist because SHA-512’s compression is faster than SHA-256’s on 64-bit processors. SHA-3 offers four fixed-output members plus the two SHAKE functions.

Where do they agree?

  1. Both are approved and neither is broken. FIPS 202 describes the SHA-3 functions as supplementing the SHA-2 family in FIPS 180-4, and both remain fully standardized and recommended.

  2. Both survive the quantum transition on identical terms. Grover’s algorithm halves preimage strength in each, leaving about half the output size, and collision resistance is barely affected in each because the classical birthday attack already found collisions in about 2^(n/2) work. Shor’s algorithm applies to neither, because a hash function has no number-theoretic structure to exploit.

  3. Both answer quantum pressure with a larger output rather than a new design. NIST’s position is that Grover’s quadratic speedup “does not render cryptographic technologies obsolete” and “can have the effect of requiring larger key sizes, even in the symmetric key case,” and for hash functions the remedy is a wider digest.

  4. Both appear inside the post-quantum standards. SLH-DSA builds on SHA-2 and SHA-3, and the SHAKE functions are used widely across the new algorithms as a pseudorandom bit source.

  5. Neither carries a retirement deadline. The 2035 disallowance applies to quantum-vulnerable public-key algorithms, and hash policy sits in the review-and-strengthen category rather than the rip-and-replace one.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov.

Does SHA-3 replace SHA-2?

No. NIST approves SHA-3 as an alternative, and both families stay fully standardized. FIPS 202 itself describes the SHA-3 functions as supplementing rather than superseding the SHA-2 family in FIPS 180-4.

The strongest public evidence for SHA-2’s standing is CNSA 2.0, which keeps hashing inside the SHA-2 family and requires SHA-384 or SHA-512 for national-security work at all classification levels. The same advisory that removes RSA and ECDH in favor of ML-KEM and ML-DSA holds SHA-2 in place and moves the dial from 256 to 384 bits rather than to a different hash family.

The suite is explicit about SHA-3 rather than merely silent on it. Asked directly whether SHA-3 can serve as a hash, the CNSA 2.0 FAQ answers that “neither SHA-3 nor SHAKE are approved for use in CNSA 2.0 as a general purpose hash algorithm,” and confines SHA3-384 and SHA3-512 to internal hardware functionality such as secure-boot integrity checks, plus the cases where an approved algorithm’s own standard prescribes it, LMS under NIST SP 800-208 being the example NSA gives. The stated reason is interoperability: SHA-2’s ubiquity in the commercial world keeps the testing burden down.

Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” CSA U/OO/194427-22, September 2022, nsa.gov; the algorithm requirements themselves are in NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ,” CSI ver. 2.1, December 2024, CNSA 2.0 table, media.defense.gov, because the announcement page states that the advisory exists and lists none of the algorithms.

When is each the right answer?

SHA-2 is the right answer for the overwhelming majority of work. It is more widely deployed, hardware-accelerated nearly everywhere, and perfectly secure, so most systems have no reason to move. SHA-256 is the sensible default for TLS certificates, code signing, package integrity and everyday authentication, with SHA-384 or SHA-512 where assurance or data lifetime demands more margin.

SHA-3 is the right answer when a design values its specific properties. Its sponge construction, built-in length-extension resistance and SHAKE extendable output make it the natural pick in new protocol designs, and it is increasingly the default inside post-quantum protocol work for exactly those reasons.

Two SHA-2 members are worth phasing out of new designs. SHA-224 and SHA-512/224 carry roughly 112-bit margins, the thinnest in the family, and SHA-256 is the natural replacement.

Why do people confuse them?

Because the version numbers imply a lineage that does not exist. SHA-1, SHA-2 and SHA-3 sound like three generations of one design, and SHA-1 genuinely was broken and genuinely was succeeded by SHA-2. The natural inference is that SHA-3 succeeded SHA-2 the same way.

It did not. SHA-2 remains unbroken and approved, and SHA-3 came out of a competition run as insurance against a break that never arrived. The naming is a numbering convention rather than a chronology of failures, which is why a team can read “we still use SHA-2” as an admission when it is simply current practice endorsed by the most conservative authority in the field.

Common misconceptions

  1. “SHA-3 replaced SHA-2 because SHA-2 was weakened.” SHA-2 has never been broken. NIST launched the SHA-3 competition in 2007 as insurance while SHA-1-lineage functions were falling, and FIPS 202 positions SHA-3 as supplementing FIPS 180-4 rather than superseding it.

  2. “SHA-3 is more quantum-resistant than SHA-2.” Their quantum posture is identical. Grover halves preimage strength in both and collision resistance is barely affected in both, so the choice between them has nothing to do with quantum safety.

  3. “We should migrate to SHA-3 for security.” There is no security-driven migration here. Move for the sponge properties, length-extension resistance or SHAKE output if a design wants them, and stay on SHA-2 otherwise.

  4. “SHA-3 is faster because it is newer.” SHA-2 is frequently faster in practice thanks to two decades of hardware acceleration including dedicated CPU instructions. Newer design and better throughput are unrelated here.

  5. “Length extension makes SHA-2 unsafe.” It makes bare SHA-2 unsafe as a message authenticator, which is precisely what HMAC solves. Used with HMAC, SHA-2 authenticates messages safely.

  6. “SHA-1, SHA-2 and SHA-3 are three generations of the same design.” SHA-1 and SHA-2 share the Merkle-Damgård lineage. SHA-3 is a different construction entirely, chosen through an open competition specifically because it was structurally unrelated.

Questions people ask

Should I migrate from SHA-2 to SHA-3? No, unless a specific design wants the sponge construction, built-in length-extension resistance or SHAKE extendable output. SHA-2 is unbroken, approved, faster in most deployments, and required by CNSA 2.0 for national-security work.

Is SHA-3 more secure than SHA-2? Neither is broken and both offer about half their output size in effective strength against the relevant attacks. SHA-3’s advantages are structural properties rather than a higher security level.

Are both quantum-safe? Both survive on the same terms. Grover halves preimage strength, so SHA-256 retains roughly 128 bits, and collision resistance is barely affected because the classical birthday bound already sat near half the output. Shor’s algorithm applies to neither.

What is length extension and does it matter to me? It is the ability to compute hash(secret || message || extra) from hash(secret || message) and the secret’s length. It matters if you use a bare hash as a message authenticator, and HMAC removes the issue for SHA-2 entirely.

What are SHAKE128 and SHAKE256? Extendable-output functions in the SHA-3 standard that produce any requested output length from one call. Post-quantum algorithms use them heavily as a pseudorandom bit source, which has made SHA-3 more visible in new cryptographic designs than its deployment share suggests.

Which SHA-2 member should I use? SHA-256 for most work, SHA-384 or SHA-512 where assurance or data lifetime demands more margin. SHA-224 and SHA-512/224 are worth phasing out of new designs, since their roughly 112-bit margins are the thinnest in the family.

Does CNSA 2.0 require SHA-3? No. It keeps hashing inside the SHA-2 family and requires SHA-384 or SHA-512 for national-security work at all classification levels. The FAQ goes further and states that neither SHA-3 nor SHAKE is approved as a general-purpose hash under CNSA 2.0, allowing SHA3-384 and SHA3-512 only for internal hardware functionality such as boot-up integrity checks.

Do the post-quantum standards use one or the other? Both. SLH-DSA builds on SHA-2 and SHA-3, and SHAKE appears across the new standards wherever a variable-length pseudorandom output is needed.

Is there a deadline to move off either? No. The 2035 disallowance covers quantum-vulnerable public-key algorithms. Hash policy is a review-and-strengthen matter, with widening the digest as the response where more margin is wanted.

The map is free and I keep it that way. When the question becomes what hash policy should actually be across an estate and which surfaces need widening, that’s the work I do at LaMarr Labs.

Go deeper

Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs.

Graph View

Backlinks