BLAKE (hash function)

• 1. Introduction

  ›

  BLAKE is a cryptographic hash function built on a foundation that began as a competition. In 2008, fifty-one different algorithms entered the NIST hash function competition, each vying to become the next standard for cryptographic hashing. Jean-Philippe Aumasson, Luca Henzen, Willi Meier, and Raphael C.-W. Phan submitted BLAKE to that contest. It survived every round of scrutiny, reaching the final five candidates before losing to Keccak in 2012, the algorithm chosen as SHA-3.

  What makes BLAKE's story interesting is not just the competition. It is what happened after. The algorithm's designers refused to let it sit on the shelf. They rebuilt it into BLAKE2, announced on the 21st of December 2012, and then rebuilt again into BLAKE3, announced on the 9th of January 2020. Three generations of a single cryptographic lineage, each faster than the last, each adopted by an expanding roster of real-world systems.

  How does a hash function that lost a standards race end up running inside WhatsApp, WireGuard, the Linux kernel, Zcash, and dozens of other critical systems? The answer involves a typo, a clever architectural choice borrowed from a stream cipher, and a design team willing to measure speed as seriously as security.

• 2. Built on ChaCha

  ›

  Daniel J. Bernstein's ChaCha stream cipher gave BLAKE its skeleton. BLAKE takes ChaCha's core quarter-round operation and adds two modifications: message words are mixed in at each step, and the rotation directions are reversed. The result runs on a 4x4 array of words, repeatedly combining an 8-word hash value with 16 message words.

  The rotation reversal has an origin story that Aumasson himself recounted in his Crypto Dictionary. "BLAKE reuses the permutation of the ChaCha stream cipher with rotations done in the opposite directions. Some have suspected an advanced optimization, but in fact it originates from a typo in the original BLAKE specifications." A mistake, preserved and standardized.

  BLAKE comes in two main variants, mirroring the structure of SHA-2. BLAKE-256 and BLAKE-224 work with 32-bit words, producing digests of 256 bits and 224 bits respectively. BLAKE-512 and BLAKE-384 work with 64-bit words, producing digests of 512 bits and 384 bits. The 64-bit version increases the number of rounds to 16, and uses different rotation amounts: 32, 25, 16, and 11.

• 3. Constants by Design

  ›

  Cryptographers worry about backdoors hidden in arbitrary constants. BLAKE addressed this concern directly by using what the field calls "nothing up my sleeve" numbers. The 16 constant words used in BLAKE's round function come from the leading 512 or 1024 bits of the fractional part of pi. Anyone can compute these values independently and verify they match.

  The initialization vectors used by BLAKE2b take a similar approach. Those eight values are the first 64 bits of the fractional parts of the positive square roots of the first eight prime numbers: 2, 3, 5, 7, 11, 13, 17, and 19. The same initialization vectors appear in SHA-512, a deliberate choice that ties BLAKE2b to an already-audited standard.

  BLAKE also uses a table of 10 permutations, labeled sigma, that govern how message words are mixed across rounds. These permutations rotate through a fixed schedule, and when the number of rounds exceeds 10, the schedule wraps back to the beginning. During the NIST competition, the design team increased the round count from 10 to 14 for the 256-bit variant and from 14 to 16 for the 512-bit variant, explicitly trading some speed for a more conservative security margin.

• 4. The Avalanche Property

  ›

  A well-designed hash function must behave unpredictably. Change a single bit of the input, and ideally every bit of the output has a fifty percent chance of flipping. This property, called the avalanche effect, is a core measure of cryptographic quality.

  BLAKE demonstrates this with documented examples. Changing a single bit in an otherwise empty input string for the 512-bit variant produces an output that differs in roughly 52 percent of bit positions, with 266 matching bits out of 512. The deviation from exactly 50 percent reflects the statistical randomness inherent in the process. The hash values themselves change dramatically even when the input change is invisible to a human reader.

  For BLAKE2b, the same experiment holds. Two inputs differing by exactly one bit produce hashes that are almost entirely different. The designers noted that this outcome matches the expected behavior of a true random function, which is the theoretical ideal against which hash functions are measured.

• 5. BLAKE2 and Real-World Adoption

  ›

  Jean-Philippe Aumasson returned for BLAKE2, joined by Samuel Neves, Zooko Wilcox-O'Hearn, and Christian Winnerlein. Their stated goal was to replace MD5 and SHA-1, two algorithms the field considered broken, in applications that needed fast software performance. BLAKE2 was announced on the 21st of December 2012, with a reference implementation released under CC0, the OpenSSL License, and the Apache License 2.0.

  On 64-bit x86-64 and ARM architectures, BLAKE2b runs faster than MD5, SHA-1, SHA-2, and SHA-3. The designers claimed better security than SHA-2, including immunity to length extension attacks and indifferentiability from a random oracle.

  Adoption came quickly and across many domains. Argon2, the winner of the Password Hashing Competition, uses BLAKE2b internally. WireGuard, the modern VPN protocol, uses BLAKE2s. The Noise Protocol Framework, which underpins WhatsApp's encryption, includes BLAKE2 as an option. Zcash uses BLAKE2b in its Equihash proof of work and as a key derivation function. The NANO cryptocurrency uses BLAKE2b for proof of work, digital signature hashing, and key derivation. FreeBSD's package management tool, GNU Core Utilities via the b2sum command, and the btrfs file system all adopted BLAKE2b. The RAR archive format version 5 supports an optional 256-bit BLAKE2sp checksum, replacing the default 32-bit CRC-32, implemented starting with WinRAR version 5. In version 5.17, the Linux kernel replaced SHA-1 with BLAKE2s for hashing the entropy pool in its random number generator.

  BLAKE2 also introduced structural flexibility. The BLAKE2X family supports extendable output functions, allowing digests of up to 256 gigabytes. BLAKE2bp and BLAKE2sp are parallel variants designed for multi-core processors, with 4-way and 8-way parallelism respectively. BLAKE2b and BLAKE2s are formally specified in RFC 7693, though the optional features like salting, personalized hashes, and tree hashing are not covered by that specification.

• 6. BLAKE3 and the Speed Mandate

  ›

  Jack O'Connor joined Aumasson, Neves, and Wilcox-O'Hearn for BLAKE3, announced on the 9th of January 2020, at the Real World Crypto conference. The design philosophy shifted. Where BLAKE and BLAKE2 were families of related algorithms, BLAKE3 is a single algorithm that handles multiple roles: a hash function, an extendable output function, a key derivation function, a pseudorandom function, and a message authentication code.

  BLAKE3 is consistently a few times faster than BLAKE2. It achieves this partly by reducing the number of rounds from 10 to 7, a change the designers justified by arguing that earlier cryptographic standards were overly conservative relative to what modern cryptanalysis actually requires. The compression function is closely based on BLAKE2s, but the binary tree structure enables a practically unlimited degree of parallelism using both SIMD instructions and multithreading. The Merkle tree format also supports verified streaming and incremental updates, two features the prior generations lacked.

  The official Rust and C implementations are dual-licensed as public domain under CC0 and the Apache License. Adoption followed a similar pattern to BLAKE2. The Bazel build system, Cargo (Rust's package manager), OpenZFS from version 2.2, ClickHouse, LLVM, and the Wasmer WebAssembly runtime all incorporated BLAKE3. The Software Bill of Materials standard CycloneDX uses it as part of its suite of hash functions, and Mosaic uses BLAKE3 instead of SHA-512 for its Ed25519 signature operations.

• 7. The India Connection

  ›

  Not every BLAKE user comes from the world of open-source infrastructure or cryptocurrency. The Open Network for Digital Commerce, a Government of India initiative, uses BLAKE-512 to sign API requests. This is a government-level deployment of a hash function that began as a competition entry, now serving as a trust anchor for a national digital commerce system.

  Aumasson's Crypto Dictionary, where he explained the rotation-direction typo, represents another kind of reach: cryptographic history written by one of the algorithm's own designers, preserving the honest account of how a specification error became a permanent feature of a widely deployed standard.