BLAKE2X
2016.12.03
https://blake2.net
Jean-Philippe Aumasson (@veorq)
Samuel Neves (@sevenps)
Zooko Wilcox-O’Hearn (@zooko)
Christian Winnerlein (@codesinchaos)
Abstract. We present BLAKE2X, a new family of BLAKE2 hash functions that produce hash values of arbitrary length—that is, extensible-output functions (XOFs). You
can use BLAKE2X within signatures schemes such as EdDSA or RSA-FDH, and also
as a DRBG or KDF.

1Introduction

Sometimes a 512-bit hash is not enough. For example, Ed521 signatures [3] need a 1056-bit
hash; RSA-FDH [2] needs a 4096-bit hash when using a 4096-bit modulus. Since BLAKE2
was limited to 512-bit hashes, and based on user demand, we present BLAKE2X, a familyof extensible-output functions (XOFs) based on BLAKE2 instances. BLAKE2X can securely
produce hash values of arbitrary size.
We designed BLAKE2X to minimize the changes from an existing BLAKE2 implementation. BLAKE2X only needs to change the value of certain parameters in BLAKE2’s parameter
block, and the implementation of a simple counter-like logic.
As a by-product, BLAKE2X provides two additional functionalities:• Deterministic random bit generator (DRBG): Given a high-entropy seed, BLAKE2X
produces a stream of up to 256 GiB.
• Key derivation function (KDF): Given input key material (and an optional salt, as allowedby the BLAKE2 parameter block), BLAKE2X computes a key of up to 232 − 2 bytes(about 4 GiB). BLAKE2X’s extract-then-expand scheme is similar (but not identical) tothat of HKDF [5, 6].

2Specification of BLAKE2X

A BLAKE2X instance can be derived from any BLAKE2 instance, be it BLAKE2b, BLAKE2s,
the parallel versions BLAKE2bp and BLAKE2sp, or any custom version defined as per theBLAKE2 specifications.
BLAKE2X requires a slightly modified version of the parameter block, where the length of
the “Node offset” field is reduced from 8 to 4 bytes for 64-bit BLAKE2, and from 6 to 4 bytes
for 32-bit BLAKE2. This change does not break compatibility with already used BLAKE2
versions. Tables 1 and 2 show the new parameter with the extra field “XOF digest length”.
Given a 64-bit BLAKE2 instance such as BLAKE2b, BLAKE2X works as follows to compute an `-byte hash of some message M:1Offset

0123048121620242832...
4448...
60

Digest length

Key length

FanoutDepth

Node depth

Leaf length
Node offset
XOF digest length
Inner length

RFU

RFU

Salt

Personalization

Table 1: BLAKE2b parameter block structure (offsets in bytes).
Offset04812162024280123

Digest length

Key length

FanoutDepth

XOF digest length

Leaf length
Node offset
Node depth

Inner length

Salt
Personalization

Table 2: BLAKE2s parameter block structure (offsets in bytes).
1. Set the “XOF digest length” parameter to a little-endian encoding of `. If the output
length is not known in advance, ` should be set to the maximal value 232 − 1 (a featuresimilar to that of KMAC [8, §4.3.1]).
2. Compute the hash of M using the underlying BLAKE2 instance as usual. Call the result
H0 . When a tree mode is used (such as BLAKE2bp), this corresponds to the root ofthe tree.
3. Create the hash function instance B2 from the BLAKE2 instance used, where:• “Key length” is set to 0 (even if the root hash was keyed)• “Fanout” is set to 0 (unlimited)• “Maximal depth” is set to 0
• “Leaf maximal byte length” is set to 32 for BLAKE2Xs, and 64 for BLAKE2Xb• “XOF digest length” is set to `• “Node depth” is set to 0 (leaves)• “Inner hash byte length” is set to 32 for BLAKE2Xs and 64 for BLAKE2Xb• Other fields are left to the same values as in the underlying BLAKE2 instance• B2(i, j, X) denotes the hash of X using i as node offset and j as digest length2

4. The final hash is computed as follows:
B2(0, 64, H0 )kB2(1, 64, H0 )kB2(2, 64, H0 )k · · · kB2(b`/64c, ` mod 64, H0 )With a 32-bit BLAKE2 (such as BLAKE2s), 64 is replaced with 32 in the last expression, and` is set to 216 − 1 when the output length is unknown in advance.
You can see BLAKE2X as the computation of an inverted tree on top of a BLAKE2 instance: first hash the message, then expands it to enough bytes to form the hash. Thisconstruction is similar to that informally described in [1, §7].
When a key is used, the key is only processed by the BLAKE2 instance that computes
H0 . The B2 instances are never keyed.
We call BLAKE2Xb` the BLAKE2X version based on BLAKE2b and producing `-bytehashes. For example, BLAKE2Xb132 produces 1056-bit digests. By default the length is inbytes but you may for example write BLAKE2Xb16MiB instead of BLAKE2Xb16777216.
When the number of bytes to generate is known in advance, ` must be set to that value.
In this case, ` is at most 232 − 2 (4 gibibytes minus two bytes) on BLAKE2Xb, and at most216 −2 (64 kibibytes minus two bytes) on BLAKE2Xs. If BLAKE2X is used as a DRBG, it must
therefore be reseeded before reaching this maximum output (and preferably before that for
better backward secrecy.)
When the number of bytes to generate is not known in advance, 64-bit BLAKE2X cangenerate up to 232 blocks of 64 bytes, that is, 256 GiB; 32-bit BLAKE2X can generate up to232 blocks of 32 bytes, that is, 128 GiB.
Note that an ` smaller or equal than 64 is acceptable, there’s just no reason to use it
since BLAKE2b already provides hashes of 64 bytes or less.

3Security

The BLAKE2X construction is similar to the counter construction proven secure in [4, §5].
The underlying BLAKE2 instances are proven to be secure [7]—indifferentiable from a random oracle—and the parameter block values ensure a domain separation between the compressing and the expanding hash trees. The resulting hash is thus expected to be at least
as secure as the underlying hash, and in particular to provide n/2-bit collision resistance,
where n is the length of H0 (or the inner hash length, if this is smaller than the digest length).
For the highest security level, the digest length n should be set to its maximal value, that is,
to 32 bytes for 32-bit BLAKE2 and to 64 bytes for 64-bit BLAKE2.
When generating hashes of unknown length (setting ` = 232 − 1 when using BLAKE2b,for example), depending on your use case you may need to use a salt to avoid ending up
with hashes of different length such that the shorter is a prefix of the longer.

4Performance

BLAKE2X adds a constant overhead of d`/64e (resp. d`/32e) compression function calls
compared to the underlying 64-bit (resp. 32-bit) BLAKE2 hash. For example, to computea 1056-bit (132-byte) hash as required in Ed521 signatures, BLAKE2X adds d132/3e = 3extra compression function calls compared to BLAKE2b. Note that B2(i, j, H0 ) calls can becomputed in arbitrary order, and in parallel.
3

References[1] Kevin Atighehchi and Alexis Bonnecaze. Asymptotic analysis of plausible tree hashmodes for SHA-3. Cryptology ePrint Archive, Report 2016/658, 2016. URL: http://eprint.iacr.org/2016/658.
[2] Mihir Bellare and Phillip Rogaway. The exact security of digital signatures - how to signwith RSA and Rabin. In EUROCRYPT, volume 1070 of LNCS, pages 399–416. Springer,
1996.
[3] Daniel J. Bernstein, Simon Josefsson, Tanja Lange, Peter Schwabe, and Bo-Yin Yang.
EdDSA for more curves. Cryptology ePrint Archive, Report 2015/677, 2015. URL: http://eprint.iacr.org/2015/677.
[4] Jean-Sébastien Coron, Yevgeniy Dodis, Cécile Malinaud, and Prashant Puniya. MerkleDamgård revisited: How to construct a hash function. In CRYPTO, volume 3621 of LNCS,
pages 430–448. Springer, 2005. Full version. URL: http://www.cs.nyu.edu/~dodis/ps/merkle.pdf.
[5] H. Krawczyk and P. Eronen. HMAC-based Extract-and-Expand Key Derivation Function (HKDF). RFC 5869 (Informational), May 2010. URL: http://www.ietf.org/rfc/rfc5869.txt.
[6] Hugo Krawczyk. Cryptographic extraction and key derivation: The HKDF scheme. In
CRYPTO, volume 6223 of LNCS, pages 631–648. Springer, 2010.
[7] Atul Luykx, Bart Mennink, and Samuel Neves. Security analysis of BLAKE2’s modes ofoperation. Cryptology ePrint Archive, Report 2016/827, 2016. URL: http://eprint.
iacr.org/2016/827.
[8] NIST. SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash.
Draft Special Publication 800-185, August 2015.
URL: http://csrc.nist.gov/
publications/PubsDrafts.html#SP-800-185.

4