BLAKE, BLAKE2 and BLAKE3¶
The SHA-3 finalist that lost to Keccak, and the faster hashes built from it: BLAKE2 in 2012, BLAKE3 in 2020.
Status and standards: see Hash functions in the main table.
What it is¶
BLAKE (Aumasson, Henzen, Meier and Phan, 2008) was one of the five finalists in NIST's SHA-3 competition. NIST found it had a very large security margin and ran extremely well in software, but chose Keccak in October 2012, partly because BLAKE is an add-rotate-XOR design like SHA-2 and Keccak is not. BLAKE itself is rarely used now; its successors are what people run.
| Function | Output | Use |
|---|---|---|
| BLAKE2b | 1 to 64 bytes | 64-bit CPUs: Argon2, libsodium, b2sum |
| BLAKE2s | 1 to 32 bytes | 8 to 32-bit CPUs: WireGuard, the Linux RNG |
| BLAKE3 | any length, 32 bytes by default | hash, MAC, KDF and XOF in one function |
BLAKE2 (Aumasson, Neves, Wilcox-O'Hearn and Winnerlein, 2012) cut the rounds, from 16 to 12 in BLAKE2b and from 14 to 10 in BLAKE2s, and built in keying, personalization and tree hashing. RFC 7693 (2015) specifies BLAKE2b and BLAKE2s with keys. It's an informational RFC, and the salt, personalization and tree modes are only in the designers' spec.
BLAKE3 (O'Connor, Aumasson, Neves and Wilcox-O'Hearn, January 2020) takes BLAKE2s's compression function, cuts it to 7 rounds and runs it over a tree. It has no variants and no RFC: an Internet-Draft (2024) expired, and the C2SP project hosts its spec.
How it works¶
BLAKE2¶
- The state is eight words (64-bit in 2b, 32-bit in 2s). They start as SHA-512's or SHA-256's initial values, with the first word XORed with a parameter block: digest length, key length and the optional fields.
- Each 128-byte (2b) or 64-byte (2s) block is compressed with a byte counter and a last-block flag. The mixing step G is built like ChaCha's quarter-round, with two message words added in.
- Keyed mode: the key, zero-padded to a full block, goes in as the first block. That's the whole MAC. RFC 7693 says BLAKE2 needs no HMAC, and prefixing the key is safe because BLAKE2 keeps BLAKE's indifferentiability proof.
- The digest length is in the parameter block, so BLAKE2b-256 is not a cut-down BLAKE2b-512.
BLAKE3¶
- The input is split into 1 KiB chunks. Each chunk is hashed like sequential BLAKE2s, 64 bytes at a time, with the chunk's index as the counter.
- Chunk results are combined in pairs, level by level, up to a root. Chunks don't depend on each other, so from 2 KiB up, SIMD lanes and threads can work on several at once.
- Three modes, set by the starting words and flags:
hashstarts from the IV,keyed_hashputs a 32-byte key in its place, andderive_keyhashes a context string first, then uses the result as the key for hashing the key material. - Output comes from compressing the root again with an output counter, 64 bytes at a time, for as long as you need. Unlike BLAKE2, a shorter output is a prefix of a longer one.
Speed¶
By the designers' numbers, BLAKE2b runs at about 3 cycles per byte on a Core i5-6600, ahead of MD5, SHA-1, SHA-2 and SHA-3 in software. One BLAKE3 thread on an Intel Cascade Lake-SP peaks at 4 times BLAKE2b and 12 times SHA-256, and more threads add more. Below 1 KiB it behaves like BLAKE2s with fewer rounds, so the big gains need long inputs.
Where it's used¶
- WireGuard: BLAKE2s as its hash, keyed BLAKE2s with 16-byte tags as its MAC, and HMAC-BLAKE2s inside its key derivation.
- Argon2: BLAKE2b hashes the inputs, and the compression function G is BLAKE2b's round with multiplications added (RFC 9106).
- Linux RNG: BLAKE2s has mixed the entropy pool since 5.17 (2022).
- libsodium:
crypto_generichashis BLAKE2b. - b2sum: in GNU coreutils since 8.26 (2016), 512-bit BLAKE2b by default.
- Zcash: BLAKE2b inside the Equihash proof of work, and personalized BLAKE2b and BLAKE2s across the protocol.
- BLAKE3: ccache moved from MD4 to it in 4.0 (2020), and the designers
list Bazel, Cargo, LLVM and OpenZFS among others.
b3sumis its command-line tool.
When to use it¶
- BLAKE2 when you want a fast software hash with a spec behind it, or a keyed hash without HMAC.
- BLAKE3 for large files, content addressing and build caches, where the tree and threads pay off, or when one function for hashing, MACs, key derivation and XOF keeps a design simple.
- SHA-2 or SHA-3 when FIPS or a protocol requires NIST algorithms. No BLAKE version is a NIST standard. And on CPUs with SHA-256 instructions, SHA-256 is often the faster one.
- Not for passwords. Use Argon2, which runs BLAKE2b inside but is built to be slow.
Example (Python)¶
import hashlib
print(hashlib.blake2s(b"abc").hexdigest())
# 508c5e8c327c14e2e1a72ba34eeb452f37458b209ed63a294d999b4c86675982
print(hashlib.blake2s(b"abc", digest_size=16).hexdigest())
# aa4938119b1dc7b87cbad0ffd200d0ae
key = bytes(range(32)) # keyed: BLAKE2s as a MAC
print(hashlib.blake2s(b"", key=key).hexdigest())
# 48a8997da407876b3d79c0d92325ad3b89cbb754d86ab71aee047ad345fd2c49
The first is RFC 7693's Appendix B value. The second is not the first
half of the first, since the length is in the parameter block. The third
is the first keyed vector in the BLAKE2 test set. blake2b works the
same way, with keys up to 64 bytes. Compare tags with
hmac.compare_digest. BLAKE3 needs the third-party blake3 package, so
it isn't shown or run here.
Security notes¶
- BLAKE2b-512 has 256-bit collision resistance and BLAKE2s-256 has 128. BLAKE3 targets 128 bits for everything, whatever the output length, though its keys are 256 bits.
- BLAKE3 has the thinnest margin, 7 rounds against BLAKE2s's 10. Its designers base that on ten years of attacks on BLAKE and BLAKE2.
- Keys must be random and secret. A BLAKE3 key is exactly 32 bytes. Salt and personalization aren't secrets; they only make hashes for different uses come out different.
See also¶
- SHA-3: the finalist that won
- HMAC / KMAC: the MAC for hashes with no key input, and SHA-3's own
- SipHash: a smaller keyed hash for short inputs
- Argon2: password hashing built on BLAKE2b
- ChaCha: where BLAKE's mixing step comes from
References¶
- NIST IR 7896: Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition (2012) (Sections 3, 4.2.1)
- Aumasson, Neves, Wilcox-O'Hearn and Winnerlein, "BLAKE2: simpler, smaller, fast as MD5" (ACNS 2013) / blake2.net
- RFC 7693: The BLAKE2 Cryptographic Hash and MAC (Sections 2, 3, 4, Appendix B) / BLAKE2 test vectors
- O'Connor, Aumasson, Neves and Wilcox-O'Hearn, "BLAKE3: one function, fast everywhere" (Sections 1–4) / BLAKE3 repository (README, adoption list) / C2SP / draft-aumasson-blake3
- Donenfeld, "WireGuard: Next Generation Kernel Network Tunnel" (NDSS 2017) (Section 5.4)
- RFC 9106: Argon2 (Sections 3.2, 3.5, 3.6)
- Zcash Protocol Specification (Sections 5.4.1.2, 5.4.1.11, 7.7.1)
- BLAKE2s commit (Linux 5.17) / libsodium: generic hashing / coreutils NEWS, 8.26 / b2sum / ccache 4.0 release notes
- Python
hashlib: BLAKE2
Weaker sources: Wikipedia, "BLAKE (hash function)" for the December 2012 release of BLAKE2.