The BLAKE2 Cryptographic Hash and MACIndependent Consultantmjos@iki.fihttps://mjos.fiKudelski Security22-24, Route de GeneveCase Postale 134Cheseaux1033Switzerlandjean-philippe.aumasson@nagra.comhttps://www.kudelskisecurity.com
General
Internet Engineering Task ForceBLAKE2Cryptographic Hash This document describes the cryptographic hash function BLAKE2, making the
algorithm specification and C source code conveniently available to the
Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized
for 64-bit platforms, and BLAKE2s for smaller architectures. BLAKE2 can
be directly keyed, making it functionally equivalent to a
Message Authentication Code (MAC). The cryptographic hash function was
designed by Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn,
and Christian Winnerlein. BLAKE2 comes in two basic flavors:
BLAKE2b (or just BLAKE2) is optimized for 64-bit platforms
and produces digests of any size between 1 and 64 bytes. BLAKE2s is optimized for 8- to 32-bit platforms, and produces
digests of any size between 1 and 32 bytes. Both BLAKE2b and BLAKE2s are believed to be highly secure and have
good performance on any platform, software or hardware. BLAKE2
does not require a special "HMAC" construction
for keyed message authentication as they have a built-in keying
mechanism. The BLAKE2 hash function may be used by digital signature algorithms and
message authentication and integrity protection mechanisms in applications
such as Public Key Infrastructure (PKI), secure communication protocols,
cloud storage, intrusion detection, forensic suites, and version control
systems. The BLAKE2 suite provides a more efficient alternative to US Secure Hash
Algorithms SHA and HMAC-SHA .
BLAKE2-128 is especially suited as a fast and more secure drop-in
replacement to MD5 and HMAC-MD5 in legacy applications
. A reference implementation in C programming language for BLAKE2b can be
found in and for BLAKE2s in
of this document. These implementations
SHOULD be validated with the Test Module contained in
. Due to space constraints, this document does not contain a full set of
test vectors for BLAKE2.
We refer to for up to date information
about compliance testing and integrating BLAKE2 into various
applications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
The following table summarizes various parameters and their
ranges:
Initialization Vector (constant).
Message word permutations (constant).
Parameter block (defines hash and key sizes).
Sixteen words of a single message block.
Internal state of the hash.
Padded input blocks. "dd" is the number of blocks.
Byte offset at the end of the current block.
Flag indicating the last block. For real-valued x we define:
Floor, the largest integer ≤ x.
Ceiling, the smallest integer ≥ x.
Positive fractional part of x, frac(x) = x - floor(x). Operator notation in pseudocode:
2 to the power "n". 2**0=1, 2**1=2, 2**2=4, 2**3=8, etc.
Bitwise exclusive-or operation between "a" and "b".
Remainder "a" modulo "b", always in range [0, b-1].
floor(x / 2**n). Logical shift "x" right by "n" bits.
(x * 2**n) mod (2**w). Logical shift "x" left by "n". (x >> n) ^ (x << (w - n)).
Rotate "x" right by "n" bits. All mathematical operations are on 64-bit words in BLAKE2b and on
32-bit words on BLAKE2b. We may also perform operations on vectors of
words. Vector indexing is zero-based; the first element of an n-element
vector "v" is v[0] and the last one is v[n - 1]. All elements is
denoted by v[0..n-1]. Byte (octet) streams are interpreted as words in little-endian
order, with the least significant byte first.
Consider this sequence of eight hexadecimal bytes:When interpreted as a 32-bit word from the beginning memory
address, x[0..3] has numerical value 0x67452301 or 1732584193.When interpreted as a 64-bit word, bytes x[0..7] have numerical
value 0xEFCDAB8967452301 or 17279655951921914625. We specify the parameter block words p[0..7] as follows: NOTE. defines additional variants of BLAKE2
with features such as salting, personalized hashes, and tree hashing.
These OPTIONAL features use fields in the parameter block which are not
defined in this document. We define the Initialization Vector constant IV mathematically as:
The numerical values of IV can be also found in implementations in
and
for BLAkE2b and BLAKE2s, respectively. NOTE. BLAKE2b IV is the same as SHA-512 IV and BLAKE2s IV
is the same as SHA-256 IV; see . Message word schedule permutations for each round of both
BLAKE2b and BLAKE2s are defined by SIGMA.
For BLAKE2b the two extra permutations for rounds 10 and 11 are
SIGMA[10..11] = SIGMA[0..1]. The G primitive function mixes two input words "x" and "y" into four
words indexed by "a", "b", "c", and "d" in the working vector v[0..15].
The full modified vector is returned. The rotation constants
(R1, R2, R3, R4) are given in . Compression function F takes as an argument the state vector "h",
zero-padded message block vector "m", 2w-bit offset counter "t",
and final block indicator flag "f". Local vector v[0..15] is used in
processing. F returns a new state vector. The number of rounds "r" is 12 for BLAKE2b and 10 for BLAKE2s.
Rounds are numbered from 0 to r - 1. We refer the reader to and
for reference C language implementations
of BLAkE2b and BLAKE2s, respectively. Key and data input is split and padded into "dd" message blocks
d[0..dd-1], each consisting of 16 words (or "bb" bytes). If a secret key is used (kk > 0), it is padded with zero bytes and set
as d[0]. Otherwise d[0] is the first data block. The final data block
d[dd-1] is also padded with zero to "bb" bytes (16 words). Number of blocks is therefore dd = ceil(kk / bb) + ceil(ll / bb).
However in special case of unkeyed empty message (kk = 0 and ll = 0),
we still set dd = 1 and d[0] consists of all zeros. The following procedure for processes the padded data blocks
into an "nn"-byte final hash value. See
for description of various variables and constants used. An implementation of BLAKE2b and / or BLAKE2s SHOULD support the following
digest size parameters for interoperability (e.g. digital signatures),
as long as sufficient level of security is attained by the parameter
selections. These parameters and identifiers are intended to be suitable
as drop-in replacements to corresponding SHA algorithms. For unkeyed hashing, developers adapting BLAKE2 to ASN.1 - based
message formats SHOULD use the OID tree at
x = 1.3.6.1.4.1.1722.12.2. The editor wishes to thank the
team for their encouragement: Jean-Philippe Aumasson, Samuel Neves,
Zooko Wilcox-O'Hearn, and Christian Winnerlein.
We have borrowed passages from
and with permission. BLAKE2 is based on the SHA-3 proposal ,
designed by Jean-Philippe Aumasson, Luca Henzen, Willi Meier, and
Raphael C.-W. Phan. BLAKE2, like BLAKE, relies on a core algorithm
borrowed from the ChaCha stream cipher, designed by
Daniel J. Bernstein.This memo includes no request to IANA. This document is intended to provide convenient open source access by
the Internet community to the BLAKE2 cryptographic hash algorithm.
We wish to make no independent assertion to its security in this
document. We refer the reader to and
for detailed cryptanalytic rationale behind its design. In order to avoid bloat, the reference implementations in
and
may not erase all sensitive data (such as secret keys) immediately
from process memory after use. Such cleanups can be added if needed.BLAKE2: simpler, smaller, fast as MD5The Hash Function BLAKEKey words for use in RFCs to Indicate Requirement Levels Updated Security Considerations for the MD5 Message-Digest
and the HMAC-MD5 AlgorithmsUS Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Implementation Guidance for FIPS PUB 140-2 and the
Cryptographic Module Validation Program This module computes a series of keyed and unkeyed hashes from
deterministically generated pseudo-random data, and computes a hash
over those results. This is fairly a exhaustive, yet compact and fast
method for verifying that the hashing module is functioning correctly. Such testing is recommended especially when compiling the implementation
for a new a target platform configuration. Furthermore, some security
standards such as FIPS-140 may require a Power-On Self Test (POST)
to be performed every time the cryptographic module is loaded
.