[cryptography] introducing BLAKE2 — an alternative to SHA-3, SHA-2 and MD5
zookog at gmail.com
Fri Dec 21 13:28:01 EST 2012
SHA-3 (Keccak) is a fine alternative to SHA-2, has a substantially
different design from the SHA-2 family, and has excellent performance
However, many use cases need an alternative to MD5 — something with
better security properties than MD5 but with high performance in
software. To that end, we've defined BLAKE2, an optimized version of
SHA-3 finalist BLAKE that is faster than MD5 on Intel 64-bit CPUs.
Target applications include cloud storage (my current field), revision
control tools, software distribution, host-based intrusion detection,
and digital forensics — areas where MD5 and SHA1 currently dominate.
We do not think that this superior software performance comes at a
cost of reduced security. We argue that much of the extensive security
analysis performed on BLAKE during the SHA-3 process applies to BLAKE2
and shows no cause for concern about BLAKE2's security. Please see the
blake2.pdf white paper for the details of that argument.
In addition, I'll make an argument here that we did not put into the
A guiding factor in NIST's choice of Keccak over BLAKE for SHA-3 was
that they wanted SHA-3 to be substantially different from SHA-2 so
that it could serve as a fallback in case a breakthrough suddenly
revealed SHA-2 to be vulnerable. This was NIST's reason for choosing
Keccak over BLAKE even though by their own estimation BLAKE's security
margin was comparable to Keccak's and the depth of cryptanalysis that
had been applied to BLAKE was greater than that applied to Keccak.
That is a good strategy for choosing an algorithm to serve as an
emergency fallback, in case SHA-2 suddenly breaks. On the other hand
if SHA-2 has remains unbroken, and you are considering the security of
BLAKE2, then the fact that it is a traditional Add-Rotate-XOR design
like SHA-2 should give increased confidence. When the SHA-3 project
began, there was concern among many cryptographers that a breakthrough
might appear at any moment and reveal SHA-2 to be vulnerable. Since
that hasn't happened after years of study, this concern has faded, and
SHA-2 appears for now to have withstood the test.
I think a similar argument could be made for the way that BLAKE2
re-uses the ChaCha/Salsa20 stream cipher, which has not been found to
have any serious vulnerability.
In addition to the superior software performance of the basic
single-threaded, linear mode, BLAKE2 includes variants optimized for
32-bit architectures, for SIMD/multicore processors, for Merkle-Tree
applications, and for message integrity checking.
I'm particularly keen on the SIMD/multicore variant, a parallelized
mode named "BLAKE2*p", because almost all modern CPUs — even a lot of
the cheap and power-efficient 32-bit ARM chips — come with efficient
SIMD features. It looks like it will be possible to have 4-way or
8-way parallelized BLAKE2*p which are many *times* as efficient as
MD5, on both short files and long files. Once we've finished porting,
measuring, and experimenting with the different modes of BLAKE on
different machines, we intend to write a "b2sum" command-line tool,
which we hope will eventually replace "md5sum" in the unix user's
(Thanks to the performance engineering of J.P.Aumasson and Samuel Neves.)
More information about the cryptography