BLAKE2 Hash Generator

Losing a standards contest is usually the end of the story for an algorithm. For one of them it was the start. NIST opened its competition for a new hash standard on November 2, 2007 and closed it on October 2, 2012 by choosing Keccak, which became SHA-3. Eleven weeks later, on December 21, 2012, the people behind one of the losing finalists announced a revised version of their own entry. They called it BLAKE2.

It was not a consolation prize. It was an argument about what most software actually needs.

The finalist NIST praised and passed over

BLAKE was one of five designs that reached the last round, named on December 9, 2010. It came from Jean-Philippe Aumasson, Luca Henzen, Willi Meier and Raphael Phan. NIST’s final report describes its heart as a block cipher working on a state that can be drawn as a four by four matrix of words, stirred by a function called G that is based on the ChaCha stream cipher of Daniel Bernstein.

The report is generous about it. BLAKE and Keccak, it says, had very large security margins. The cryptanalysis of BLAKE had a great deal of depth. Designs built from addition, rotation and exclusive or, the family BLAKE belongs to, performed extremely well in software. Keccak, for its part, had a clear advantage in hardware.

What tipped the choice was something BLAKE could not fix by being good. The report notes that SHA-2 is the same kind of software-oriented design as BLAKE, so an attack on one is more likely to carry over to the other. NIST wanted a spare that failed differently. Keccak, a sponge built on a different plan from SHA-2, was that spare.

So the world had a new standard that complemented the old one, and still no answer to an older complaint: the standard hashes were slower than the broken ones people kept using. The BLAKE2 paper opens on exactly that. MD5, long known to be vulnerable to collisions, was still doing integrity checks in storage systems and version control because it was fast.

What was cut to make it quick

The designers of BLAKE2, Aumasson again with Samuel Neves, Zooko Wilcox-O’Hearn and Christian Winnerlein, went through BLAKE with a knife. Their paper lists the cuts one by one. Rounds came first. BLAKE had been raised during the contest to 16 rounds for its 64-bit version and 14 for its 32-bit one, for the sake of caution and not because of any attack. BLAKE2 settles on 12 and 10 rounds, which the paper says gives a direct speed-up of about 25 and 29 percent on long inputs. The authors are plain that this does not lower security as far as anyone can show, and that it does lower the margin.

Two rotation amounts were changed so that common processors can do them in fewer instructions. The sixteen constants that BLAKE mixed into every step were dropped, leaving eight. Bytes are read in little-endian order, the order most processors already use. The counter counts bytes, not bits.

The padding went too. Older designs append the message length to the end of the data, which can cost a whole extra block. BLAKE2 pads the last block with zero bytes only if it has to, and tells the compression function that a block is the last one by flipping a flag. A message that fills its final block exactly gets no padding at all. That rule is also the easiest part to get wrong: the last full block must be the flagged one, not an empty block after it.

The result, the abstract says, is often faster than MD5 on 64-bit platforms. It comes in two sizes. BLAKE2b uses 64-bit words and gives a digest of any length from 1 to 64 bytes. BLAKE2s uses 32-bit words, for small processors, and gives 1 to 32 bytes.

Sixteen words on a grid

The machinery is small enough to hold in your head. A chaining value of eight words carries the result so far. To absorb a block, the function lays out 16 words in a grid: the chaining value in the top two rows and eight fixed constants in the bottom two. The byte counter is mixed into one of the bottom words and the last-block flag inverts another.

Then G goes to work. Each call takes four words of the grid and two words of the message and mixes them with additions, exclusive ors and rotations. One round is eight calls: down the four columns, then along the four diagonals. A table called SIGMA decides which two message words each call receives, and it reorders them every round, so every message word meets every part of the state. After the last round the top and bottom halves are folded back into the chaining value.

The eight constants have a pedigree anyone can check. RFC 7693 defines them as the fractional parts of the square roots of the first eight primes, and notes that they are the same numbers SHA-512 and SHA-256 start from. The federal standard for SHA-2 describes its initial values in the same words.

You can follow one block in the tool above. Leave the text as abc and the variant as BLAKE2b at 512 bits. The digest begins ba80a53f and ends 09923, the value RFC 7693 works out step by step in its appendix. The step view has 100 steps: the start, the set-up, twelve rounds of eight, the fold and the digest. Switch on the hexadecimal words and go to the third step. The first message word reads 0000000000636261, which is c, b, a backwards, because bytes are read little end first. Press Next round, and the first word of the state reads 86b7c1568029bb79, exactly as the appendix prints it.

Now choose 256 bits. The digest becomes bddd813c and so on, with nothing in common with the first one. This surprises people who know SHA-3’s extendable functions, where a longer output starts with the shorter one. In BLAKE2 the digest length is written into the very first block, so each length is a different function. Python’s documentation says it in one line: shorter hashes are not prefixes of longer hashes.

A key slot, a salt and a name tag

That first block is where BLAKE2 keeps its extras. Before any data arrives, a parameter block is combined with the starting constants. It holds the digest length, the key length, a salt and a personalization string, and some fields for hashing in a tree that a plain hash leaves at fixed values.

The key is the important one. With SHA-2, turning a hash into a message authentication code takes a wrapper. HMAC, defined in RFC 2104, hashes the message with one padded form of the key and then hashes that result with another. The care is needed partly because SHA-2 allows length extension, a property NIST’s report says the SHA-3 candidates were required to resist. BLAKE2 was built to resist it, so its keyed mode is simple: the key, padded to one block, goes in front of the message. The RFC says outright that no separate HMAC construction is required. The paper adds that this saves at least one call to the compression function.

The salt and the personalization are not in the RFC, which covers the core algorithm and says these optional fields are defined in the BLAKE2 paper. Each is exactly 16 bytes in BLAKE2b and 8 in BLAKE2s. A salt makes two hashes of the same data differ. A personalization string gives each use inside a program its own function, so a digest made for one purpose cannot be passed off for another. Libraries differ in how they take them. Python accepts shorter values and pads them with zero bytes, so a salt and the same salt followed by a zero byte are the same thing.

A worked case, from Python’s own documentation: the key pseudorandom key, the message message data, and a digest of 16 bytes give 3d363ff7401e02026f4a4687d4863ced. Type the three into the tool and it should agree.

Where it ended up, and what it is not

BLAKE2 never became a federal standard. Neither FIPS 180-4 nor FIPS 202 includes it. What it has instead is RFC 7693, published in November 2015, and a long list of adopters.

Argon2, the memory-hard password function described in RFC 9106, uses BLAKE2b as its hash. The Noise Protocol Framework names BLAKE2s and BLAKE2b among its hash functions. The Linux kernel’s random number driver keeps its entropy pool as a BLAKE2s state. The designers’ own site adds that the WireGuard VPN uses BLAKE2s for hashing and as a MAC. On the command line, GNU coreutils ships b2sum, which prints a 512-bit BLAKE2b checksum in the same layout as its older siblings, and Python has both variants in its standard library.

The limits are worth stating as plainly as the strengths. A digest shows that two sets of bytes are the same; it cannot say who made them, so the expected value has to come from somewhere you trust. A keyed digest shows that its maker held the key, and nothing more. The b2sum command knows only plain BLAKE2b, so a keyed, salted or BLAKE2s checksum cannot be checked with it. And speed, the whole point of the design, is the wrong property for passwords. The designers say so themselves and point to Argon2, which is deliberately expensive.

Nor is BLAKE2 the last of its line. BLAKE3, announced in 2020 by a team that includes three of the same designers, is built on an optimized instance of BLAKE2 arranged as a tree, so that many processor cores can share the work. Its authors describe it as one algorithm with no variants and a default output of 256 bits.

That leaves three families side by side. SHA-2 is the incumbent that never broke. SHA-3 is the insurance policy, different by design. BLAKE2 is the one nobody was required to use, and that so many chose anyway because it asked for less: fewer rounds, fewer constants, no wrapper for a key. A contest can pick a winner. It cannot stop the runner-up from being useful.