SHA-256 vs SHA-3: Merkle–Damgård or sponge

SHA-256 vs SHA-3 compares the workhorse of the SHA-2 family with the Keccak-based standard NIST published in 2015. Neither is broken or close to it, and both offer the same nominal security at the 256-bit output size. They differ in internal design, which affects length extension, speed and how they are used inside newer algorithms.

At a glance

Throughput measured with openssl speed -evp on one core of an Apple M4 Max, which has hardware support for both families.

Design

SHA-256 processes the message in 64-byte blocks, feeding each into a compression function together with the previous 256-bit state; the final state is the digest. Because the digest is the entire internal state, anyone who knows SHA-256(x) and the length of x can continue hashing and compute SHA-256(x ‖ padding ‖ y) without knowing x. That length extension is harmless for signatures and HMAC but breaks naive MACs such as SHA-256(key ‖ message).

SHA-3 is a sponge: it absorbs input into a 1600-bit state through the Keccak-f permutation and squeezes output from part of it. For SHA3-256, 1088 bits of the state form the rate and 512 bits the capacity, which is never output, so length extension is impossible and SHA3-256(key ‖ message) is a sound MAC (NIST standardizes KMAC for that). The same sponge yields the extendable-output functions SHAKE128 and SHAKE256, which post-quantum algorithms use to expand seeds into matrices and noise.

NIST selected Keccak in 2012 after a five-year competition that started when attacks on MD5 and SHA-1 raised fears about SHA-2's similar structure. Those fears did not materialize: the best attacks on SHA-256 reach about 31 of 64 steps for collisions, and the full function shows no weakness. SHA-3 is therefore a hedge, not a replacement.

Speed

On the Apple M4 Max, both families have instructions, yet SHA-256 is almost three times faster for long inputs: about 2.85 GB/s against 1.01 GB/s for SHA3-256 in OpenSSL 3.6.5, with SHA3-512 at 0.53 GB/s. On x86 CPUs with SHA extensions the picture is similar; on processors with no hash instructions SHA-3 and SHA-256 are closer, and BLAKE2 or BLAKE3 are faster than both. For most applications either is far faster than the I/O around it; it matters for hashing very large files, Merkle trees and blockchains.

SHA3-256 is not Keccak-256

Ethereum adopted Keccak before FIPS 202 was final, and FIPS 202 then changed the padding (adding domain-separation bits). The two functions share the permutation but give unrelated digests. Solidity's keccak256, the web3_sha3 RPC and every Ethereum address, function selector and EIP-712 digest use Keccak-256. Calling a library's SHA3-256 in Ethereum code produces wrong results without any error.

import { createHash } from "node:crypto";
import { keccak_256 } from "@noble/hashes/sha3.js";

const input = Buffer.from("abc");
console.log("SHA-256   ", createHash("sha256").update(input).digest("hex"));
console.log("SHA3-256  ", createHash("sha3-256").update(input).digest("hex"));
console.log("Keccak-256", Buffer.from(keccak_256(input)).toString("hex"));

SHA-256    ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA3-256   3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532
Keccak-256 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45

The SHA-256 and SHA3-256 values match the FIPS 180-4 and FIPS 202 examples for "abc".

When to choose which

• Protocol interoperability (TLS, certificates, JWT, SSH, Git, package managers, Bitcoin): SHA-256, because that is what the other side computes.
• Keyed hashing: HMAC-SHA256 works with any SHA-2 hash; if you prefer a simple keyed construction, KMAC or keyed SHA-3 avoid HMAC's double pass.
• Seed expansion, deterministic random streams, variable-length output: SHAKE256 or SHAKE128.
• Post-quantum algorithms: whatever the standard fixes internally; ML-KEM and ML-DSA use SHA3 and SHAKE, so libraries implementing them already include SHA-3.
• Ethereum: Keccak-256, never FIPS SHA3-256.
• A second, structurally different hash for defense in depth (for example dual hashing of long-term archives): SHA-3 alongside SHA-256.
• Raw speed without a FIPS requirement: BLAKE2 or BLAKE3 on CPUs without hash instructions.

Migration notes

Switching hash functions changes every digest, so it is a format change rather than a library swap.

1. Version the identifier: record the algorithm with each digest (sha256:, sha3-256:, multihash, an OID), as content-addressed systems such as container registries and SRI do.
2. Dual-publish during transition: compute both digests, verify whichever the consumer knows, retire the old one when consumers have upgraded.
3. Check length-extension assumptions: if code builds MACs as hash(secret ‖ message), moving to SHA-3 fixes it, but moving to HMAC fixes it for SHA-256 too.
4. Mind truncation and encodings: digests travel as hex, base64 or base64url; mismatched encodings are more common than mismatched algorithms.
5. Do not migrate for quantum reasons alone: both functions keep at least 128-bit preimage security against Grover's algorithm, and NIST's draft transition plan keeps both in service.

References

• FIPS 180-4, Secure Hash Standard
• FIPS 202, SHA-3 Standard
• NIST SP 800-185, cSHAKE, KMAC, TupleHash, ParallelHash
• NIST SP 800-107 Rev. 1, applications using approved hash algorithms
• NIST IR 8547 ipd, Table 7 (hash strengths)
• RFC 2104, HMAC