SHA-2 vs SHA-3: two different machines

Somebody has specified SHA3-256 and your tooling gives you SHA-256, or a reviewer has asked why anything still uses SHA-2 when SHA-3 exists. Both questions come from the same reasonable assumption: that a cryptographic standard with a higher number replaced the one below it, the way TLS 1.3 replaced TLS 1.2.

That is not what happened here. SHA-2 was standardized in 2002 and has no practical weakness in 2026. SHA-3 was published in 2015 and is not a patch, an upgrade, or a deprecation notice. Both are approved, both are in active use, and the choice between them is almost never a security decision. This page covers where SHA-3 came from, the one structural difference that can genuinely change the behavior of code you write, and what should actually decide which you pick — if you just want the recommendation for a specific job, which hash algorithm to use gets there faster.

The single sentence worth carrying away: SHA-3 was not commissioned because SHA-2 looked weak. It was commissioned because SHA-2 was the only thing left.

Why two unbroken standards exist at once

Follow the family tree and the reasoning becomes obvious. MD4 appeared in 1990 and MD5 in 1991. SHA-0 arrived in 1993, SHA-1 as a corrected version of it in 1995, and the SHA-2 family in 2002. Every one of them is an iterated design in the Merkle–Damgård shape — cut the message into blocks, push each block through a compression function along with a running state — and every one of them inherits design ideas traceable back to MD4. SHA-2's compression function is much harder to attack than SHA-1's: eight working variables instead of five, and a message schedule that mixes nonlinearly rather than by XOR and rotation, which is exactly the part the 2005 attacks pulled apart. It is not a longer SHA-1 — SHA-256 runs 64 rounds against SHA-1's 80. The skeleton is the same skeleton.

Then 2004 and 2005 happened. Xiaoyun Wang and her colleagues produced working collisions for MD5 and published a theoretical attack that put a SHA-1 collision at 2 to the power of 69 rather than the 2 to the power of 80 it should have cost. The alarming part was not that two old functions had fallen; it was that the attack technique went after the shared design, which meant nobody could argue the same methods would never reach SHA-2. And at that point essentially every certificate, signature and package manifest on earth depended on functions from one lineage. There was no second family to fall back on.

So NIST ran an open competition, the same way AES had been chosen. Sixty-four submissions arrived in 2008, fifty-one were accepted into the first round, fourteen went through to the second, and five reached the final: BLAKE, Grøstl, JH, Keccak and Skein. Keccak, from Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche, was selected in October 2012 and standardized as FIPS 202 in August 2015.

And then the thing the competition was insuring against did not happen. Twenty-four years of public cryptanalysis later there is still no collision for any member of SHA-2, and no result that comes close to the full function. So SHA-3 has spent its entire deployed life as a spare — standardized, implemented, audited, and not needed. That is a success, not an embarrassment, and it is why you see both.

The two machines, side by side

The row that matters most is the one about internal state. A SHA-256 digest is the function's complete internal state at the moment the message ran out — hand somebody the 64 characters and you have handed them everything the algorithm knew. Keccak keeps a 1,600-bit state and splits it in two: a rate the message is allowed to touch and a capacity it never is, and only the rate is ever read back. SHA3-256 withholds 512 bits of capacity, which is why it absorbs 136 bytes at a time rather than a round number. Generating a SHA-3 hash goes through the absorption step by step.

What the table cannot show is that the digests are unrelated. Both families produce 64 hexadecimal characters at the 256-bit size and 128 at the 512-bit size, and nothing in the value tells you which one made it. The empty input is the cheapest way to see it, because every implementation can produce both:

Same length, same alphabet, no relationship. If you are holding a 64-character value and a file that will not match it, the family is worth ruling out before the file is — identifying which algorithm a checksum came from covers the other lengths that collide like this.

The one difference that can bite your code

Everything above is architecture. Here is the place where it turns into a bug somebody actually shipped.

Because a SHA-256 digest is the whole internal state, anyone holding a digest can carry on hashing from it. Suppose a service authenticates requests by computing SHA-256(secret + parameters) and sending the result along. An attacker who has one valid request can resume the chain from that digest, append whatever they like, and produce a digest that is valid for the longer message — without ever learning the secret. They need only guess the secret's length, and there are not many plausible lengths. This is not hypothetical: Flickr's API signing scheme fell to exactly this attack in 2009 — it used MD5 rather than SHA-256, but the weakness belongs to the construction rather than to the algorithm, and SHA-256 shares it. The same pattern has turned up in webhook signatures and payment callbacks since.

A sponge has nothing to extend. The capacity was never in the digest, so resuming the state is not possible, and that makes a plain keyed hash like SHA3-256(key + message) sound in a way the SHA-2 equivalent is not. NIST standardized that pattern as KMAC in SP 800-185 rather than leaving people to improvise it.

One member of SHA-2 is immune for a quiet reason: SHA-384 runs the SHA-512 machine and then throws away 128 bits of the final state, so a digest no longer reveals enough to resume from. That is a side effect of truncation rather than a design goal, and it is one of the few genuine arguments for choosing SHA-384 over SHA-512.

Which is faster on a Mac

SHA-2, though by less than the folklore claims. Apple Silicon carries instructions for both families: four that compute SHA-256's round function outright, and a second set — EOR3, RAX1, BCAX, XAR — that accelerates the Keccak permutation without performing a whole round. The dedicated round instructions do more of the work, so SHA-256 reaches roughly 2 GB/s and SHA3-256 trails it. On an older Intel Mac, which has neither set, the two run close enough that speed decides nothing.

In practice the gap usually disappears, because the disk is slower than either. Hashing a file on an external drive takes as long as reading the file, whichever algorithm you asked for — why hashing is slow works through the bottlenecks in order, and the algorithm is almost never the one.

Each family also has an internal surprise, and they point in opposite directions. In SHA-2, SHA-512 usually outruns SHA-256 in software because it works in 64-bit words and chews through 128 bytes per compression rather than 64. In SHA-3 the wider digest genuinely costs more: SHA3-512 holds back twice the capacity, so it absorbs only 72 bytes per permutation against SHA3-256's 136, and runs the permutation nearly twice as often per byte. Bigger is cheaper in one family and dearer in the other.

Which one should you use

• You are comparing against somebody else's value. Then there is no choice to make — use the function they used, or you are comparing two unrelated numbers. This covers almost every download you will ever verify.
• A specification, contract or auditor names SHA-3. Use SHA-3, and resist the urge to hand over a SHA-256 because it is what your tooling produces. Both are FIPS-approved; substituting one for the other fails the requirement and nobody will notice until it matters.
• You need a keyed hash and cannot use HMAC. SHA-3 or KMAC is the better foundation, for the reason in the section above.
• You are recording fingerprints that must still mean something in twenty years. Record both. Two digests from two unrelated designs cost one extra row and no extra read, and an advance against one has no reason to touch the other.
• You want the newer one because it is newer. This is the one bad reason, and you pay for it in tooling: nothing that comes with macOS computes SHA-3, so everybody you hand a SHA3-256 to needs something installed before the value means anything. A checksum nobody can reproduce is a checksum that gets skipped.

That last point is the real cost of the newer family, and it is the reason SHA-256 remains the correct default even though SHA-3 is a fine function. A checksum is a thing you publish so other people can check it. Its value depends on how easily they can.

Troubleshooting

Both values are 64 characters and they still do not match

Check the family before you check the file. A SHA3-256 and a SHA-256 of the same bytes are both 64 hex characters and will never agree, and the failure looks identical to a damaged download — which is how people end up re-downloading a 4 GB ISO three times. If the published value came out of something labeled only “SHA-256”, you want the SHA-2 row; if the specification said SHA3-256, you want the SHA-3 row. Rocket Hash keeps the two families under their own group headings for this reason, so the wrong row is hard to copy by accident.

My tools only offer SHA-2 and the spec says SHA-3

That is the normal situation on a Mac rather than something wrong with your setup: macOS ships nothing that computes SHA-3, so the family is simply absent until you add it. In Rocket Hash both members have their own rows under the SHA-3 group heading — SHA3-256 and SHA3-512 — free in the Text tool and selectable from the Algorithm control in Files. For a one-off value, the SHA3-256 generator here does the same arithmetic in the browser.

Should we migrate our published checksums to SHA-3?

Not on general principle. SHA-2 has no practical weakness, and moving a release pipeline to a family most of your users cannot compute with the tools they have trades a real inconvenience for a theoretical benefit. Migrate when a requirement tells you to, or publish both and let people use whichever they can verify, which costs you one extra column in the manifest and costs your users nothing.

Somebody told me SHA-3 is post-quantum and SHA-2 is not

Both families are in the same position, and it is a comfortable one. Quantum algorithms threaten RSA and elliptic-curve cryptography because those rest on problems a quantum computer solves efficiently; hash functions rest on nothing of the kind. Grover's algorithm offers at best a square-root speedup against finding a preimage, which a 256-bit output absorbs, and the known quantum approaches to collisions need impractical amounts of storage for a modest gain. Nothing about a sponge is more quantum-resistant than a chain.

Which one does the rest of the world actually use?

SHA-256, overwhelmingly, for downloads, certificates, package managers and content addressing. SHA-3 turns up where a standards body chose it deliberately — certain government profiles, some newer protocol designs, and a handful of cryptocurrencies — and in libraries as an available option nobody has switched to. If you are deciding what to publish rather than what to check, follow the crowd here; being unusual costs your readers effort.

Frequently asked questions

Has SHA-2 been broken?

No. There is no collision for any member of the SHA-2 family, no practical preimage attack, and nothing in more than twenty years of public cryptanalysis that comes near the full function. The published results work on deliberately weakened versions with rounds removed, and the gap between those and the real algorithm is wide. SHA-3 exists as insurance against a break, not as a response to one.

Why did NIST create SHA-3 if SHA-2 was not broken?

Because in 2005 every widely used hash function came from one design lineage, and the attacks that destroyed MD5 and undermined SHA-1 went after ideas that lineage shared. If the same methods had reached SHA-2 there would have been no alternative to deploy. NIST ran an open competition from 2007, chose Keccak in 2012 for being structurally unrelated to everything before it, and published it as FIPS 202 in 2015.

Can I use SHA3-256 where a SHA-256 is expected?

No. They are different functions that happen to produce the same 64 hexadecimal characters, and their digests have no relationship — substituting one produces a value that will never match and gives no hint why. If you are checking somebody's published checksum you must use the function they used.

What is a length-extension attack, and does it affect file checksums?

It lets somebody who holds a SHA-256 digest continue hashing from it and produce a valid digest for a longer message, because the digest is the function's entire internal state. It matters when a digest is used as a signature over a secret plus a message, which is why HMAC exists. It cannot affect an ordinary file checksum, because there is no secret involved and nothing for the attacker to gain by appending bytes you would notice.

Which is faster, SHA-2 or SHA-3?

SHA-2, on any recent Mac, but not by the margin people expect. Apple Silicon has instructions for SHA-256's round function and a second set that accelerates the Keccak permutation, so neither family is left doing plain arithmetic — SHA-256 reaches roughly 2 GB/s and SHA3-256 trails it. For files the difference rarely shows, since both are faster than a disk can supply data.

Will quantum computers break SHA-2 or SHA-3?

Neither, as far as anyone can currently argue. Grover's algorithm reduces the work of finding a preimage to roughly the square root of the search space, which leaves a 256-bit digest with about 128 bits of margin, and quantum collision-finding needs storage that makes it worse than classical methods in practice. The algorithms at risk from quantum computers are RSA and elliptic curves, not hash functions.