Why Replace SHA-1 with BLAKE2?

Unless you’ve lived under a rock for the last twelve years, you must know that the cryptographic hash function SHA-1 is broken, in the sense that it’s not as secure as it should be: SHA-1 produces 160-bit digests, meaning that finding a collision (or two messages hashing to the same value) should take approximately 2⁸⁰ operations, thanks to the birthday attack. But in 2005 cryptanalysts discovered that collisions can be found with much fewer operations, somewhere in the ballpark of 2⁶⁵ operations. That’s bad, because many applications using SHA-1 become insecure if collisions are practical to find. And that count of operations,  2⁶⁵, is on the verge of being practical— it’d take ages with your laptop, but for a big organization with skills and money on their hands, computing a SHA-1 collision is  just a matter of weeks .

Google is one such organization, which used its enormous compute power (clusters of CPUs and clusters of GPUs) to implement an optimized distributed collision search based on research by CWI‘s Marc Stevens and Pierre Karpman. The colliding messages are the following:

(Image lazily copied from Marc et al.’s research paper)

And since we’re in 2017, the collision comes with a pun and a logo: http://shattered.io/

That’s an amazing result, the outcome of years-long cryptanalysis by Marc Stevens and other researchers, and the product of Google’s engineering capabilities. But it’s no surprise, we’ve seen it coming for years:

Still, this actual collision makes the threat more real to many, who’ve kept using SHA-1 and now look for an alternative. To replace SHA-1, I recommend BLAKE2, a hash algorithm designed by yours truly jointly with Samuel Neves, Zooko, and CodesInChaos. The points below summarize why I think replacing SHA-1 with BLAKE2 is a good idea:

Because SHA-1 is Broken

Duh! You don’t want to use a broken hash.

Well, it depends. Only SHA-1’s collision resistance is broken, not its preimage resistance (the problem of finding a message mapping to a given hash value). Some applications don’t require collision resistance, but only preimage resistance. For example, it’s still safe to use HMAC-SHA-1 (the HMAC pseudorandom function with SHA-1 as a hash function), or PBKDF2-HMAC-SHA-1 (the PBKDF2 password hash with HMAC-SHA-1 as a pseudorandom function). But when in doubt, ditch SHA-1.

Because BLAKE2 is Secure

BLAKE2 targets the highest possible security for a hash function, no attack has ever been found on BLAKE2 since its publication in 2012. In fact, BLAKE2 is based on BLAKE, a hash function submitted to the SHA-3 competition in 2008 and reviewed for four years by the best cryptanalysts in the world, without any notable finding. In its final report, NIST said that  BLAKE has a “very large security margin.”

Furthermore, BLAKE2’s internals are based on ChaCha, a stream cipher designed by Daniel J. Bernstein and one of the three ciphers in TLS 1.3, the new TLS standard. ChaCha is highly trusted, and unlikely to ever be broken.

Because BLAKE2 is Faster than SHA-1

Thanks to design choices and implementation optimizations, BLAKE2 often outperforms SHA-1. For example, the chart below shows the throughput of various hash functions on a recent Intel CPU (Skylake microarchitecture). You will find more benchmark results on eBACS.

Because it’s Easy

You will find implementations of BLAKE2 in most common languages, such as C, Go, Java, JavaScript, Python, or Rust. BLAKE2 is, for example, part of Go’s /x/crypto package. BLAKE2 is also included in the most popular crypto libraries, including OpenSSL and Sodium, and again you’ll have bindings for common languages (see here for Sodium).

Because BLAKE2 Does Everything You Need

BLAKE2 is more than just a hash function like SHA-1!

First, BLAKE2 comes in two main versions: BLAKE2b, a 64-bit version producing hashes of any length up to 512 bits, and BLAKE2s, a 32-bit version producing hashes of any length up to 256 bits.

For even faster hashing, the parallel versions BLAKE2bp and BLAKE2sp can run on multiple cores in parallel, and be up to eight time faster than their serial counterparts.

To use keyed hashing—that is, pseudorandom functions (PRF) or message authentication codes (MAC)—based on BLAKE2, you don’t need to implement a dedicated construction such as HMAC. Instead, BLAKE2 accepts a key as an optional input, and gets you a keyed hash as secure as HMAC (and also faster!).

If you need hash values longer than 512 bits, for example to implement a key derivation function (KDF) or deterministic random bit generator (DRBG), we created BLAKE2x, a simple extension of BLAKE2 that can produce hash values of any length, even very long ones.

Why Not Use SHA-2 or SHA-3 Instead?

SHA-2 is the family of hash functions including SHA-256 and SHA-512, and providing variants for 224- and 384-bit hash values. SHA-2 hash functions can be seen as more secure versions of SHA-1, and they’re indeed unbroken as of this publication. However, SHA-2 hash functions are noticeably slower than BLAKE2, don’t support extra features, and are vulnerable to the length extension attack.

SHA-3 is the family of hash functions standardized as the US Federal Standard FIPS 202 in 2015, based on Keccak, the winner of the SHA-3 competition. SHA-3 hash functions are as secure as BLAKE2, but slower in software as the chart above shows. In hardware, however, SHA-3 is much faster than BLAKE2! Another possible good reason to use SHA-3 is compliance; BLAKE2 is not a formal standard (though it’s an RFC), and it’s not FIPS-approved unlike SHA-3.

Now What?

When reviewing source code for cryptographic flaws, I often run a command like grep -Hnri md5 (or, better, rg -i md5) in order to look for MD5 usage, and therefore potential vulnerabilities. I suggest you do the same in your systems for both MD5 and SHA-1, and upgrade to a more secure hash such as BLAKE2 if necessary.

In particular, if you use X.509 certificates, make sure to use SHA-256 rather than SHA-1 in the signature algorithm. Domain name certificates using SHA-1 will be marked as insecure by web browsers such as Chrome:

After MD5 and SHA-1 were announced to be theoretically broken in 2005, many developers postponed an upgrade to SHA-2 and kept using insecure algorithms because they were faster than the more secure alternative. There is no such excuse now: in software BLAKE2 is faster than (or about as fast as) SHA-1, and in hardware SHA-3 is faster than SHA-1. The bottom line is that you’ve everything to gain from removing SHA-1 from your systems!