The BLAKE family of hash functions is one of the most successful stories in modern cryptography. BLAKE started as a SHA-3 candidate, lost the competition to Keccak, and then evolved into BLAKE2 in 2012, which became one of the most widely deployed alternatives to SHA-2 in real production code. BLAKE3, published in 2020, took the design even further, achieving speeds that hardware-accelerated SHA-256 cannot match on most modern CPUs. Understanding the family tree, what changed at each step, and where each variant is the right choice today, is a useful tour of how a hash function design can evolve through generations and stay competitive.
The SHA-3 Competition and BLAKE's Roots
In 2007, NIST opened a public competition to select a hash function that would become SHA-3, the successor to SHA-2. The motivation was that SHA-1 had been broken in 2004-2005, SHA-2 was conceptually similar to SHA-1 and might face similar attacks in the future, and the cryptographic community wanted a structurally different hash function as a backup.
51 candidates were submitted. NIST narrowed them down through three rounds of analysis, ending with five finalists: BLAKE, Grostl, JH, Keccak, and Skein. After extensive analysis, NIST selected Keccak as SHA-3 in 2012, primarily because it was structurally most different from SHA-2 and used a sponge construction rather than Merkle-Damgard.
BLAKE, designed by Jean-Philippe Aumasson, Luca Henzen, Willi Meier, and Raphael Phan, came in second in many of the public votes among cryptographers. The Keccak win was based on diversity of construction rather than security or performance: BLAKE was faster and equally secure but used a more conventional design, which made it less attractive as a "different from SHA-2" backup.
After losing the SHA-3 competition, the BLAKE designers had a choice. They could let the design fade, or they could refine it for the real-world use cases that NIST had not optimized for. They chose the latter and produced BLAKE2.
BLAKE2: The Practical Hash
BLAKE2 was published in 2012 by Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn, and Christian Winnerlein. The design philosophy was explicit: take BLAKE, simplify the structure, drop a few rounds, and optimize for real-world software performance on the platforms that actually matter.
BLAKE2 came in two main variants. BLAKE2b is the 64-bit version, optimized for 64-bit CPUs. It produces hashes from 1 to 64 bytes long, with the common output being 32 or 64 bytes. BLAKE2s is the 32-bit version, optimized for 8-bit, 16-bit, and 32-bit CPUs. It produces hashes from 1 to 32 bytes long, with the common output being 16 or 32 bytes.
The internal structure uses a permutation similar to BLAKE's, with a 16-word state for BLAKE2b (using 64-bit words) or BLAKE2s (using 32-bit words). The compression function processes input in 128-byte blocks for BLAKE2b or 64-byte blocks for BLAKE2s, applying 12 rounds for BLAKE2b or 10 rounds for BLAKE2s.
The design includes built-in support for keyed hashing, salt, personalization strings, and tree hashing modes. This was a significant departure from SHA-2, which provided only a basic hash interface and required separate constructions like HMAC for keyed authentication.
BLAKE2 was published as IETF RFC 7693 in 2015, giving it standardized international recognition. Adoption was rapid. Argon2, the password hashing standard, uses BLAKE2b internally. WireGuard uses BLAKE2s for some authentication operations. Many file integrity tools, version control systems, and content addressable storage systems adopted BLAKE2 because it was faster than SHA-256 in software and had clear security analysis.
How BLAKE2b and BLAKE2s Differ
The choice between BLAKE2b and BLAKE2s depends on the platform and the use case.
BLAKE2b is the right choice for almost any modern application running on a 64-bit CPU. It uses 64-bit operations natively, which means each round processes 8 bytes per word and the cipher fully exploits the 64-bit data path. Output sizes up to 64 bytes give you the full 512-bit hash that SHA-512 also provides, but with significantly better software performance.
BLAKE2s is the right choice for embedded systems, IoT devices, and other constrained environments where the CPU is 32-bit or smaller. The 32-bit operations match the hardware's natural data path, while BLAKE2b would force the CPU to emulate 64-bit operations through pairs of 32-bit instructions. For a 32-bit CPU, BLAKE2s is several times faster than BLAKE2b in real benchmarks.
For modern desktop, server, and mobile platforms, BLAKE2b is the default. For embedded firmware, microcontrollers, and very small devices, BLAKE2s is the default.
BLAKE3: The Speed Champion
BLAKE3 was published in January 2020 by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn. The same team behind BLAKE2 went back to the drawing board with the goal of making the fastest practical hash function consistent with strong security.
The BLAKE3 design takes BLAKE2 and applies three major changes. First, the compression function is reduced from 10 or 12 rounds to 7 rounds. Cryptanalysis of BLAKE2 showed that 7 rounds was a comfortable security margin, and dropping to 7 rounds gives a substantial speed boost. Second, the design unifies BLAKE2b and BLAKE2s into a single function with one parameter set, eliminating the choice between 64-bit and 32-bit variants. Third, BLAKE3 uses a tree hash structure natively, which means it can hash large inputs in parallel across multiple CPU cores.
The result is a hash function that is several times faster than SHA-256 even with hardware acceleration. On a typical modern CPU, BLAKE3 hashes data at 1 to 2 gigabytes per second per core in pure software, and scales nearly linearly with the number of cores. SHA-256 with SHA-NI hardware acceleration tops out around 2 gigabytes per second on the same CPU but does not scale across cores.
BLAKE3 also includes built-in support for keyed hashing, key derivation, and extendable output. The output length can be any size, from a few bytes to gigabytes, which makes it suitable for use as a stream cipher or as a deterministic random number generator.
BLAKE3 has not yet been formally standardized through IETF or ISO. It is published as an open specification, has been extensively analyzed, and is widely deployed in production systems including QNSQY itself.
The 7-Round Question
The reduction from 10-12 rounds to 7 rounds in BLAKE3 was the most discussed design change. Hash function designers traditionally favor conservative round counts, leaving comfortable headroom against future cryptanalysis. The BLAKE3 team argued that the cryptanalysis of BLAKE and BLAKE2 had shown the round function was strong enough that 7 rounds was sufficient.
The argument is that the BLAKE family has been analyzed extensively for over a decade. The best published attacks reach around 4 to 5 rounds for collision attacks and similar reduced-round numbers for other attack classes. A 7-round full hash leaves 2 to 3 rounds of margin, which is consistent with how security margins are typically measured.
After 5+ years of public scrutiny since BLAKE3 was published, no practical attack has approached the 7-round design. The conservative argument has been validated in practice, although the theoretical question of whether 7 rounds will hold up over 20+ years remains.
For the contrasting design philosophy, see Serpent Cipher Explained. Serpent doubled its round count from the minimum to 32, taking a much larger performance penalty for additional margin. BLAKE3 went the other direction, trimming rounds for speed and accepting the tighter margin.
Where Each Variant Is Used
BLAKE2b is the most common BLAKE variant in production. Argon2 uses it internally for password hashing. The IPFS content-addressable storage system supports it. Many file integrity tools, including b2sum on Linux, use BLAKE2b as the default. WireGuard uses BLAKE2s for some operations and BLAKE2b for others.
BLAKE2s is most common in embedded and constrained-device contexts. Some IoT firmware uses it for integrity checking. WireGuard uses it for the TAI64N timestamp authentication.
BLAKE3 is gaining adoption rapidly, especially in performance-critical applications. The Rust ecosystem has adopted BLAKE3 widely through the official blake3 crate. Content-addressable storage systems are migrating to BLAKE3 for the speed improvement. QNSQY uses BLAKE3 as its primary hash function. Some Bitcoin and cryptocurrency tools have considered BLAKE3 for non-protocol-critical operations.
For applications that need standardization through IETF or ISO/IEC, BLAKE2b is the safer choice. For applications that prioritize raw speed and can accept a published-but-not-yet-formally-standardized primitive, BLAKE3 is the choice.
BLAKE Family in Argon2
The most cryptographically important use of BLAKE2 is inside Argon2, the password hashing standard. Argon2 uses BLAKE2b as its underlying compression function. Every Argon2 password hash you have ever seen was computed using BLAKE2b internally.
The reason Argon2 picked BLAKE2 over SHA-2 is performance. Password hashing is intentionally expensive, but the expense should come from the memory-hard structure of Argon2, not from the underlying hash being slow. BLAKE2b is significantly faster than SHA-512, which gives Argon2 better performance per unit of memory hardness.
For the full Argon2 picture, see Argon2id Explained. The relationship between BLAKE2b and Argon2id is one of the cleanest examples of cryptographic primitives composing well: a fast hash function enables a high-quality password hashing scheme that would not be practical with a slow hash function.
BLAKE Family and Post-Quantum Cryptography
Hash functions are not directly broken by quantum computing. Grover's algorithm gives a quadratic speedup against preimage and second-preimage attacks. The BHT algorithm gives a cube-root speedup against collision attacks.
For BLAKE2b-256 or BLAKE3-256, this means 128 bits of effective post-quantum preimage resistance and 85 bits of effective post-quantum collision resistance. The collision number is below modern recommendations, so for long-lived signature applications, BLAKE2b-512 or BLAKE3-512 are preferable. They give 256 bits of effective post-quantum preimage resistance and 170 bits of effective post-quantum collision resistance.
The BLAKE family will continue to be useful in the post-quantum era. The migration concentrates on asymmetric primitives, key exchange and digital signatures, where Shor's algorithm provides exponential speedups. Hash functions are unaffected by Shor's algorithm.
For the post-quantum picture, see What Is Post-Quantum Cryptography, ML-KEM Explained, and Why RSA-2048 Will Break.
How QNSQY Uses BLAKE3
QNSQY uses BLAKE3 as its primary hash function for file integrity, key derivation, and various internal operations. The choice of BLAKE3 over SHA-2 is driven by performance: BLAKE3 is several times faster on modern CPUs and supports parallel hashing across cores, which is important for large file encryption.
QNSQY does use SHA-2 in places where compatibility with NIST FIPS standards is required. The hybrid post-quantum primitives in QNSQY combine ML-KEM with X25519 and ML-DSA with Ed25519. Ed25519 internally uses SHA-512, so SHA-2 appears in the QNSQY stack indirectly through that primitive.
Argon2id is used for password-based key derivation. Argon2id uses BLAKE2b internally, so BLAKE2b also appears in the QNSQY stack indirectly.
The result is a hash function story in QNSQY that includes BLAKE3 (primary), SHA-512 (via Ed25519), and BLAKE2b (via Argon2id). Each is used where it is the right tool, with no national or alternative hash functions added beyond the international defaults.
For the broader QNSQY architecture, see BLAKE3 Hashing, Hybrid Encryption, and Argon2id Explained.
Frequently Asked Questions
Is BLAKE3 more secure than BLAKE2? On the cryptographic merits, both are secure with no published practical attacks. BLAKE3 has fewer rounds (7 versus 10-12 for BLAKE2), which gives it a tighter security margin. The BLAKE3 team argues that 7 rounds is sufficient based on extensive cryptanalysis. After 5+ years of public scrutiny, no attack has approached the 7-round design.
Which BLAKE variant should I use? For modern 64-bit platforms with no need for formal standardization, use BLAKE3 for raw speed or BLAKE2b for IETF-standardized status. For embedded or constrained devices, use BLAKE2s. For applications that need NIST FIPS compliance, use SHA-256 or SHA-512 instead.
Is BLAKE3 standardized? As of early 2026, BLAKE3 has not been formally standardized through IETF or ISO/IEC. It is published as an open specification with reference implementations and has been extensively analyzed. BLAKE2 is standardized through IETF RFC 7693 and is in ISO/IEC.
Why is BLAKE3 so fast? Three reasons: fewer rounds (7 versus 10-12), unified design (no 32-bit/64-bit variants), and native parallel tree hashing. The parallel design is the biggest factor for large inputs: BLAKE3 can use multiple CPU cores simultaneously, while SHA-256 and BLAKE2 cannot.
Will BLAKE3 hold up long-term? The 7-round design is more aggressive than typical conservative crypto designs. Whether this holds up over 20+ years of cryptanalysis is an open question. For applications that need maximum long-term safety margin, BLAKE2b or SHA-512 may be preferable. For applications that prioritize speed and accept the tighter margin, BLAKE3 is the right choice.
Sources
- Aumasson, J.-P. et al. "BLAKE2: simpler, smaller, fast as MD5." Applied Cryptography and Network Security 2013. https://www.blake2.net/blake2.pdf
- IETF RFC 7693. "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)." 2015. https://datatracker.ietf.org/doc/html/rfc7693
- O'Connor, J., Aumasson, J.-P., Neves, S., Wilcox-O'Hearn, Z. "BLAKE3: one function, fast everywhere." 2020. https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf
- NIST. "Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition." 2012. https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf
- NIST FIPS 180-4. "Secure Hash Standard (SHS)." 2015. https://csrc.nist.gov/pubs/fips/180/4/final
- NIST FIPS 202. "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions." 2015. https://csrc.nist.gov/pubs/fips/202/final
Related Articles
- BLAKE3 Hashing
- Argon2id Explained
- What Is Post-Quantum Cryptography
- NIST FIPS Guide
- Hybrid Encryption
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.