SHA3-256: The Sponge Construction and How It Differs From SHA-256
SHA3-256 is the 256 bit SHA-3 function from FIPS 202, built on the Keccak sponge rather than the Merkle-Damgard chain used by SHA-2. It has the same 64 character output as SHA-256 and none of its length extension weakness.
At a glance
- Digest size
- 256 bits
- Hex characters
- 64
- Rate and capacity
- Rate 1088 bits (136 bytes) absorbed per permutation, capacity 512 bits held back
- Standard
- FIPS 202 (2015), the SHA-3 family, based on the Keccak permutation
- Broken for collisions
- No. No practical attack on the full function
- Safe for password storage
- No. Use a memory-hard password hash such as Argon2id, scrypt or bcrypt
- Available in the generator
- Yes. Note its digest differs from Keccak-256 despite the same length
In detail
SHA-3 is a sponge. The state is a 1600 bit block; input is absorbed 1088 bits at a time, with a fixed permutation applied between absorptions, and the remaining 512 bits of capacity are never touched by input directly. Output is then squeezed out of the state. This is a structurally different idea from SHA-2, where a compression function folds each block into a chaining value that becomes the digest.
The practical consequence is that the digest is not the full internal state, so there is nothing for an attacker to resume. SHA3-256 is immune to length extension, which means the naive construction hash(secret + message), forgeable with SHA-256, is not forgeable here. That does not make it a good design; HMAC or KMAC is still the right way to authenticate, but the failure mode is absent.
SHA-3 was standardised in 2015 after a public competition, explicitly as a structurally independent backup rather than a replacement for SHA-2. If a breakthrough ever attacked the Merkle-Damgard family, SHA-3 would be unaffected, and vice versa. That is its job. SHA-2 has not been broken, so SHA-3 has not displaced it, and SHA-256 remains the more widely supported choice.
The cost is speed and support. Without hardware acceleration SHA3-256 is typically slower than SHA-256 on the same machine, and support in older libraries, databases and command line tools is patchier. Choosing it means checking that every consumer of the digest can compute it, which is exactly the check people forget until a downstream service returns a mismatch.
The confusion that actually bites people is with Keccak-256. Ethereum uses the original Keccak padding, standardised SHA-3 uses a different padding byte, and the two produce completely different 64 character digests for the same input. They are not interchangeable. And like everything else here, SHA3-256 is wrong for password storage: use Argon2id, scrypt or bcrypt, which ToolBox does not provide.
Examples
input: "" -> a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
input: "abc" -> 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532input "abc":
SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA3-256 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532
Keccak-256 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45All three are 64 hex characters. The generator computes all three at once, which is the fastest way to work out which one a system produced.
Things that catch people out
- SHA3-256 and Keccak-256 differ only by a padding byte and give entirely different digests. If you are integrating with anything in the Ethereum ecosystem, you almost certainly want Keccak-256.
- Some older tools expose a function called sha3 that is actually Keccak, because they were written before FIPS 202 was finalised. Verify against the published digest of the empty string before trusting the name.
- SHA3-256 has no length extension weakness, but that is not permission to roll your own authentication. Key placement, canonical encoding and constant time comparison are still your problem.
- SHA-3 is not automatically 'stronger' than SHA-2. Both target 128 bit collision resistance at 256 bits of output, and neither has a practical attack.
Try it: Hash Generator
Paste text or drop a file and get every digest at once, in hex or Base64, with a verify tab for comparing an expected value against what you actually have.
Hash Generator
LOCAL · Browser-OnlyGenerate MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512, Keccak-256, CRC32, and HMAC hashes from text or files
MD5 is cryptographically broken and should not be used for security purposes. Use SHA-256 or SHA-512 instead.
Related Hash algorithms
All hash algorithms →Keccak-256: Ethereum's Hash and Why It Is Not SHA3-256
Keccak-256 uses the original Keccak padding, not the FIPS 202 padding. Same 64 hex characters as SHA3-256, completely different values. Why Ethereum uses it.
SHA3-512: Maximum Sponge Capacity and When to Choose It
SHA3-512 outputs 128 hex characters and holds back 1024 bits of capacity, halving throughput versus SHA3-256. What that buys and when it is worth it.
SHA-256: The Default Choice and How It Is Used
SHA-256 gives a 64 character hex digest with no practical collision or preimage attack. Where it belongs, where it does not, and its length extension flaw.
HMAC-SHA-1: Still Sound Even Though SHA-1 Collisions Are Not
HMAC-SHA-1 produces a 40 character tag and is not affected by the SHA-1 collision attacks. Why that is true, and where it is still deployed today.
HMAC-SHA-256: Signing and Verifying Payloads Correctly
HMAC-SHA-256 gives a 64 character authentication tag. Why it replaces hash(secret + body), how webhook signatures use it, and how verification goes wrong.
HMAC-SHA-384: 384 Bit Tags and the 128 Byte Block Size
HMAC-SHA-384 gives a 96 character tag over a 128 byte block. Where JWT HS384 and TLS use it, and why the key length threshold is different.
Tools for this
- Hash Generator Free online hash generator - generate MD5, SHA-1, SHA-256 hashes from any input text