SHA-3, BLAKE2 and BLAKE3
How a sponge construction differs from Merkle-Damgard, where SHA-3 fits alongside SHA-2, the BLAKE2 variants and their speed, and what BLAKE3 adds with tree hashing.
Two constructions, three families
| Algorithm | Construction | Speed | Notable property |
|---|---|---|---|
| SHA-256 / SHA-512 | Merkle-Damgard | Moderate, widely accelerated | Ubiquitous; not extension resistant |
| SHA-3 (Keccak) | Sponge | Slower in software than SHA-2 | Different structure, so SHA-2 breaks do not transfer |
| SHAKE128/256 | Sponge, extendable output | Similar to SHA-3 | Variable-length output from one primitive |
| BLAKE2b / BLAKE2s | HAIFA-style, ChaCha core | Faster than SHA-256 in software | Built-in keying and salt |
| BLAKE3 | Merkle tree over a BLAKE2s-like core | Very fast, parallel and SIMD | One primitive for hashing, keying, KDF and XOF |
# SHA-3 and SHAKE from the command line
printf 'hello' | openssl dgst -sha3-256
printf 'hello' | openssl dgst -shake256 -xoflen 64
# BLAKE2 ships with many standard tools
printf 'hello' | b2sum -l 256
printf 'hello' | openssl dgst -blake2b512One primitive, several modes
import hashlib
# SHA-3 family
hashlib.sha3_256(b"hello").hexdigest()
hashlib.shake_256(b"hello").hexdigest(32) # 32 bytes of output, your choice of length
# BLAKE2 with native keying, salt and personalisation
key = b"0123456789abcdef"
mac = hashlib.blake2b(b"message", key=key, digest_size=32)
mac.hexdigest()
# BLAKE2 can act as a KDF via the person and salt parameters
hashlib.blake2b(b"context", digest_size=32,
salt=b"saltsaltsaltsalt",
person=b"app-v1 ").hexdigest()- The sponge construction absorbs the input and then squeezes output, which is why one algorithm can produce any output length.
- SHAKE is an extendable-output function: useful for deriving keys, not just for a fixed digest.
- BLAKE2b is faster than SHA-256 on 64-bit CPUs without hardware acceleration, and about as fast with it.
- Keyed BLAKE2 is a genuine MAC and does not suffer length extension, so it can replace HMAC when both ends support it.
BLAKE3 and tree hashing
BLAKE3 splits the input into chunks, hashes them in parallel and combines them with a Merkle tree. That makes it the fastest mainstream hash on large inputs and gives it verification properties for free.
import blake3
h = blake3.blake3(b"hello")
print(h.hexdigest())
# extendable output, like SHAKE
print(h.digest(length=64).hex())
# keyed mode, a real MAC
mac = blake3.blake3(b"message", key=b"0" * 32).hexdigest()
# derive a subkey, changing the domain without changing the key
sub = blake3.blake3(b"context", derive_key_context="session token v1").hexdigest()[:32]| Task | Recommended | Why |
|---|---|---|
| File integrity at scale | BLAKE3 or SHA-256 | BLAKE3 is far faster; SHA-256 is universally available |
| MAC for a protocol | HMAC-SHA256 | Every platform implements it |
| MAC in a performance path | Keyed BLAKE2 or BLAKE3 | One pass, faster than HMAC |
| Long-lived signatures | SHA-256 or SHA-512 | Standardised and well analysed |
| Deriving keys | HKDF-SHA256 or BLAKE3 derive_key | Purpose-built, domain separated |
| Post-quantum-conscious choice | SHA-3 or SHAKE | Different structure from SHA-2 |
💡
A newer hash is not automatically a safer one. SHA-3 has been standardised since 2015 and is well analysed; a brand-new algorithm with a smaller review history is a different kind of risk. Prefer standardised options unless speed is the deciding constraint.
FAQ
Should I use SHA-3 instead of SHA-256?
Only if you need a different construction, extendable output, or an organisational policy requires it. SHA-256 remains secure and is much better supported and hardware accelerated.
Is BLAKE3 safe for signatures?
It is well designed and becoming standardised, but signing ecosystems are conservative. Use SHA-256 or SHA-512 for signatures and keep BLAKE3 for high-throughput integrity work.
Related
Collisions, birthday attacks and length extension Choosing a hash: a decision guide
Last refreshed 2026-09-18.