← Back to Blog

BLAKE3: The Fastest Cryptographic Hash Function

BLAKE3: The Fastest Cryptographic Hash Function - QNSQY post-quantum encryption guide

What Is Hashing? The Fingerprint Analogy

Before we get into BLAKE3 specifically, you need to understand what hashing is. Think of it like a fingerprint scanner for files.

When police take your fingerprint, they press your finger onto a pad and get a unique pattern. That pattern does not contain your entire body. You cannot reconstruct a person from a fingerprint. But you can use it to verify identity: scan the finger again later and check if the pattern matches. Two different people will always produce different fingerprints.

A cryptographic hash function works the same way, but for digital data. You feed in a file of any size, from a single-character text file to a 100 GB video, and the hash function produces a fixed-size output (typically 256 bits, or 32 bytes). That output is called a digest or hash. It is a unique fingerprint of the data.

Four properties make a hash function useful for security:

  • One-way: Given a hash, you cannot reverse it to find the original input. There is no "decrypt" for a hash. The process is mathematically irreversible. This is different from encryption, where you can always reverse the operation if you have the key. A hash is a one-way street.
  • Deterministic: The same input always produces the same hash. Feed in the same file a million times, you get the same digest every time. Change a single comma in a document, and the hash changes completely.
  • Collision-resistant: It is computationally infeasible to find two different inputs that produce the same hash. With a 256-bit hash, there are 2256 possible outputs, which is more than the number of atoms in the observable universe. The probability of accidentally finding two files with the same hash is essentially zero.
  • Avalanche effect: Changing a single bit of input changes roughly half the bits of the output. If you have a 1 GB file and change one character in the middle, the hash looks completely different. Similar inputs produce wildly dissimilar hashes. There is no way to predict how the hash will change.

Where Hashes Are Used (You Encounter Them Daily)

Hash functions are one of the most fundamental tools in all of computer security. You interact with them constantly, even if you do not realize it:

  • File integrity: When you download software, the website often publishes a hash (sometimes called a "checksum") alongside the download link. After downloading, you can hash the file yourself and compare the result. If the hashes match, the file was not corrupted or tampered with during transfer.
  • Password storage: Responsible websites never store your actual password. They store a hash of your password. When you log in, they hash what you typed and compare it to the stored hash. If an attacker steals the database, they get hashes, not passwords. (This is simplified; in practice, password hashing uses special algorithms like Argon2id, which we cover in a separate article.)
  • Digital signatures: When you digitally sign a document, the software does not sign the entire document (which could be gigabytes). Instead, it hashes the document down to 32 bytes and signs the hash. The recipient hashes the document themselves and verifies the signature against their hash. This is orders of magnitude faster than signing the full data.
  • Git version control: Every commit in Git is identified by a hash (a SHA-1 hash, specifically). The hash includes the file contents, the commit message, the author, and the timestamp. Change any of these, and the commit hash changes. This is how Git detects tampering with repository history.
  • Blockchain: Every block in a blockchain contains the hash of the previous block. Change anything in an earlier block, and its hash changes, which breaks the chain for every subsequent block. This is the fundamental integrity mechanism behind Bitcoin and similar systems.
  • Key derivation: In encryption systems, you often need to combine multiple pieces of secret material into a single encryption key. Hash functions (or hash-based functions like HKDF) are used to derive uniform, fixed-size keys from variable inputs.

The Problem with SHA-256 (And Why BLAKE3 Exists)

For decades, the standard hash function was SHA-256, published by NIST as part of FIPS 180-4. SHA-256 is secure. No one has found a way to break it. The cryptographic community has studied it extensively, and it remains solid.

But SHA-256 has a performance limitation that becomes painful as files get larger. SHA-256 processes data sequentially. It takes a 512-bit (64-byte) block, hashes it, takes the output, feeds it into the next block, hashes that, and so on. Each block depends on the result of the previous block. This means you cannot parallelize SHA-256. You cannot use multiple CPU cores to hash a file faster. You cannot use SIMD (Single Instruction, Multiple Data) instructions effectively. No matter how many cores your processor has, SHA-256 runs at the speed of a single core.

On modern hardware, SHA-256 achieves about 300-400 MB/s on a single core. That sounds fast, and for small files it is. But consider hashing a 100 GB backup archive, or verifying the integrity of a multi-terabyte database. At 400 MB/s, a 100 GB file takes over four minutes. On a server with 64 CPU cores, 63 of them sit idle while one core does all the work.

BLAKE3 was designed to solve this exact problem. Published in January 2020 by Jean-Philippe Aumasson, Jack O'Connor, Samuel Neves, and Zooko Wilcox-O'Hearn, BLAKE3 is a hash function that is both cryptographically strong and built for parallelism from the ground up.

How BLAKE3 Works: The Merkle Tree

The fundamental insight behind BLAKE3 is a data structure called a Merkle tree. Instead of processing data block by block in a chain (like SHA-256), BLAKE3 splits the input into 1 KiB (1,024-byte) chunks, hashes each chunk independently, and then combines the results in a tree structure.

Imagine you have a book with 1,000 pages. The SHA-256 approach is to read page 1, summarize it, then read page 2 and update the summary, then page 3, and so on. You must read every page in order. The BLAKE3 approach is to hand each page to a different person, have them all summarize their page simultaneously, then combine the summaries in pairs (summary of pages 1-2, summary of pages 3-4, etc.), then combine those pairs, and so on until you have one final summary. With enough people (or CPU cores), the entire book can be processed in a fraction of the time.

The Merkle tree advantage: Because each chunk is hashed independently, BLAKE3 can use every CPU core, every SIMD lane, and even multiple machines in parallel. An 8-core CPU can hash roughly 8 times faster than a single core. SHA-256 is locked to one core no matter what hardware you have.

The internal compression function of BLAKE3 is derived from BLAKE2s, which in turn is based on the ChaCha quarter-round designed by Daniel Bernstein. The lineage matters because each ancestor has been heavily analyzed:

  1. ChaCha (2008): A stream cipher designed by Daniel Bernstein with a quarter-round function that provides excellent diffusion and is efficient in software. Used in WireGuard, TLS, and many other protocols.
  2. BLAKE (2008-2012): A hash function based on ChaCha that was one of five finalists in the NIST SHA-3 competition. It was one of the most-analyzed hash designs ever produced, having undergone four years of public scrutiny by the global cryptographic community.
  3. BLAKE2 (2012): A faster successor to BLAKE. BLAKE2s (the 32-bit variant) is used in the Linux kernel random number generator, the WireGuard VPN, the Argon2 password hashing algorithm, and many other systems.
  4. BLAKE3 (2020): Adds the Merkle tree structure for parallelism, reduces the number of rounds from 10 to 7 (justified by extensive cryptanalysis of BLAKE and BLAKE2), and includes SIMD-optimized implementations.

The reduction from 10 rounds to 7 might sound like it weakens security, but it does not. The original 10-round BLAKE had a very large security margin. Cryptanalysts found that even with significant round-reduction attacks, BLAKE's structure held up. The BLAKE3 authors determined that 7 rounds provide a comfortable security margin while allowing higher throughput.

Speed: The Numbers

Raw performance is where BLAKE3 separates itself from every other widely used hash function. Here are benchmarks on typical modern hardware:

Hash Function Single-Core Speed 8-Core Speed SIMD Optimized?
BLAKE3 ~1 GB/s ~8 GB/s Yes (AVX-512, AVX2, SSE4.1, NEON)
SHA-256 ~300-400 MB/s ~300-400 MB/s Limited (SHA-NI on some CPUs)
SHA-3 (Keccak) ~200-300 MB/s ~200-300 MB/s No
BLAKE2s ~500-600 MB/s ~500-600 MB/s Limited
MD5 (broken, do not use) ~800 MB/s ~800 MB/s No

BLAKE3 on a single core is already faster than MD5, an older hash function that has been broken and should never be used for security. On multiple cores, BLAKE3 leaves everything else behind by an enormous margin. On a 32-core server, BLAKE3 can hash at 30+ GB/s.

To put this in practical terms: hashing a 25 GB file with SHA-256 takes about 25-30 seconds, regardless of how powerful your computer is. Hashing that same file with BLAKE3 takes roughly 10 seconds on a single core, or about 1.5 seconds on an 8-core machine. When you are processing large datasets, verifying backups, or checking the integrity of thousands of files, this difference adds up quickly.

BLAKE3 vs SHA-256: A Full Comparison

Property BLAKE3 SHA-256
Speed (single core) ~1 GB/s ~300-400 MB/s
Parallelism Yes (Merkle tree) No (sequential)
Multi-core scaling Linear None
Default output size 256-bit (extendable) 256-bit (fixed)
Standardization IETF draft NIST FIPS 180-4
Classical security 256-bit preimage 256-bit preimage
Post-Grover security 128-bit 128-bit
Quantum-safe Yes Yes

Both BLAKE3 and SHA-256 provide the same level of quantum resistance. Grover's algorithm reduces their preimage resistance from 256-bit to 128-bit, which is still computationally infeasible. The choice between them is about performance and flexibility, not security.

SHA-256 has the advantage of NIST FIPS standardization, which matters for government compliance and regulatory requirements. If your organization must use FIPS-certified algorithms, SHA-256 is the standard choice. BLAKE3 has the advantage of raw speed and parallelism, which matters when you are hashing large volumes of data in the real world.

One additional feature of BLAKE3 is that its output is extendable. SHA-256 always produces exactly 256 bits. BLAKE3 can produce output of any length. Need a 512-bit hash? BLAKE3 can do that without running the full algorithm twice. This flexibility is useful for key derivation and other applications where different output sizes are needed.

Security Properties: Is Faster Less Secure?

A common misconception is that faster means less secure. After all, if BLAKE3 processes data three times faster than SHA-256, is it cutting corners on security?

No. The speed advantage comes from better engineering, not from weaker cryptography. There are two reasons BLAKE3 is faster:

Parallelism through structure. SHA-256's sequential chain design means the CPU spends most of its time waiting for the previous block to finish before starting the next one. BLAKE3's Merkle tree lets it process many chunks at the same time. This does not reduce security. Each individual chunk is hashed with the same level of cryptographic rigor. The tree structure simply organizes the work more efficiently.

Efficient use of modern hardware. BLAKE3 was designed to take advantage of SIMD instructions (AVX-512, AVX2, SSE4.1, NEON) that are present in all modern CPUs. These instructions can perform the same operation on multiple pieces of data simultaneously. SHA-256 was designed in 2001 when these capabilities were far less common, and its internal structure does not benefit from them to the same degree.

The security of BLAKE3 rests on the same cryptographic foundations as its predecessors. The compression function has been analyzed for over 15 years through the BLAKE/BLAKE2/BLAKE3 lineage. No practical attack has been found against any version. The reduction from 10 rounds (BLAKE2) to 7 rounds (BLAKE3) is supported by formal analysis showing that the security margin remains comfortable.

BLAKE3 as a Multi-Purpose Cryptographic Tool

Unlike SHA-256, which is purely a hash function, BLAKE3 was designed from the start to serve multiple roles. It has three built-in modes:

  • Hash mode: The standard hash function. Takes any input and produces a fixed-size digest. This is the mode used for file integrity checking and content addressing.
  • Keyed hash mode (MAC): Takes a secret key and a message, and produces an authentication tag. This is used for message authentication codes (MACs), where you want to verify both the integrity and the origin of a message. Only someone with the key can produce a valid tag.
  • Key derivation mode (KDF): Takes key material and a context string, and derives a fixed-size key. This is similar to HKDF but built directly into the hash function. It is used to turn shared secrets (from key exchange) into symmetric encryption keys.

Having all three modes in a single, well-analyzed function means you do not need to combine multiple primitives. SHA-256 requires separate constructions for MAC (HMAC-SHA-256) and KDF (HKDF-SHA-256). BLAKE3 includes all three natively, reducing the number of things that can go wrong in a cryptographic system.

How QNSQY Uses BLAKE3

BLAKE3 appears at multiple critical points throughout the QNSQY encryption system:

  • File integrity verification: Every .qs encrypted file includes a BLAKE3 hash of the original plaintext, computed before encryption. After decryption, the hash is recomputed and compared. If the hashes do not match, something went wrong (disk corruption, a bug, or tampering), and QNSQY alerts you immediately rather than silently producing garbage output.
  • Key derivation (hybrid KEM): When QNSQY performs a hybrid key exchange, ML-KEM produces one shared secret and X25519 produces another. These two secrets need to be combined into a single encryption key in a way that is secure even if one of the underlying algorithms is compromised. BLAKE3 is used to hash both secrets together, producing a uniform 256-bit key that depends equally on both inputs.
  • Machine key derivation: QNSQY uses BLAKE3 to derive a machine-specific key from hardware identifiers. This key is used for local caching and does not leave the machine.
  • Content hashing command: The qnsqy hash -i file command computes a BLAKE3 hash of any file. This is useful for verifying downloads, comparing files across systems, or generating integrity manifests for a directory of files.
  • Hash verification command: The qnsqy hash-verify -i file --hash <expected> command checks a file against a known BLAKE3 digest and returns a simple pass/fail result.

The performance advantage of BLAKE3 is most noticeable when working with large files. For a 25 GB file, BLAKE3 completes in roughly 10 seconds on a single core, or under 2 seconds on an 8-core machine. SHA-256 would take 25-30 seconds with no multi-core benefit. When encrypting or verifying large datasets, backups, or media files, the difference is substantial.

BLAKE3 and Quantum Computers

Like AES, hash functions are resistant to quantum computers. Grover's algorithm can speed up hash preimage searches (finding an input that produces a given hash), but the speedup is quadratic, not exponential. For a 256-bit hash function, Grover's algorithm reduces preimage resistance from 2256 to 2128, which is still far beyond any feasible computation.

For collision resistance (finding any two inputs that produce the same hash), the quantum speedup is even less dramatic. Classical collision finding takes 2128 operations for a 256-bit hash. Quantum algorithms reduce this to roughly 285, which is still a massive number.

The bottom line is that both BLAKE3 and SHA-256 are considered quantum-safe at the 256-bit output level. NIST's post-quantum guidance confirms that 256-bit hash functions provide adequate security in the quantum era.

Sources

  1. Aumasson, J.-P., O'Connor, J., Neves, S., Wilcox-O'Hearn, Z. "BLAKE3: one function, fast everywhere." 2020. github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf
  2. NIST FIPS 180-4: Secure Hash Standard (SHS), August 2015. csrc.nist.gov/publications/detail/fips/180/4/final
  3. NIST FIPS 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015. csrc.nist.gov/publications/detail/fips/202/final
  4. Aumasson, J.-P. et al. "BLAKE2: simpler, smaller, fast as MD5." 2013. Applied Cryptography and Network Security, ACNS 2013.
  5. Bernstein, D. J. "ChaCha, a variant of Salsa20." 2008. cr.yp.to/chacha/chacha-20080128.pdf

Questions people ask

What is BLAKE3?

BLAKE3 is a cryptographic hash function released in 2020. It produces a 256-bit digest by default, uses a Merkle-tree structure that parallelizes across CPU cores, and is significantly faster than SHA-2 and SHA-1 on most modern processors while remaining collision- and preimage-resistant.

Is BLAKE3 quantum-safe?

Yes, for practical purposes. Quantum computers attack hashes with Grover's algorithm, which only halves effective security: BLAKE3's 256-bit output retains roughly 128-bit quantum preimage resistance. Hash functions are not broken by Shor's algorithm the way RSA and ECC are, so BLAKE3 is considered quantum-resistant.

Is BLAKE3 faster than SHA-256?

On most modern CPUs, yes, often by a large margin. BLAKE3 processes input in a parallelizable tree using SIMD instructions, so throughput scales with cores and vector width. Dedicated SHA-256 hardware instructions narrow the gap, but for large inputs BLAKE3 typically remains the faster choice.

What is BLAKE3 used for?

File integrity verification, content-addressed storage, key derivation, and deduplication. QNSQY uses BLAKE3 for integrity verification of encrypted data and for keyfile-based key derivation, alongside NIST post-quantum algorithms for key encapsulation and signatures.

Related Articles

Fast Integrity Checking

QNSQY uses BLAKE3 for all internal hashing: fast, secure, parallelizable.

Try QNSQY

Originally published at quantumsequrity.com/blog/blake3-hashing.