Catalin was quoting me in the article, so it's only fair that I elaborate here.
There are four common flavors of the SHA2 family you're likely to run into:
- SHA-224
- SHA-256
- SHA-384
- SHA-512
And then there are two more variants of "truncated SHA-512" (except they also use different initialization vectors than SHA-512, which is kind of an important detail)
- SHA-512/256
- SHA-512/224
These latter two don't have
nearly the cross-platform support as the first four.
For example, in PHP, hash('sha256', 'some text') worked since PHP 5.1.2 (without PECL), but hash('sha512/256', 'some text') didn't work until PHP 7.1.0 (which is only a few years old).
See for yourself: https://3v4l.org/A1dZc
As a typical software developer, you might see SHA-{magic/numbers} and probably discover from Google/StackOverflow/etc. that they're in the SHA2 family and that the SHA2 family is secure, and then reason that whatever you're doing must also be also secure.
But there's a problem.
SHA-256 and SHA-512 (not the truncated varieties) are known to be vulnerable to length extension attacks. This is only a problem if you're using these hash functions in a vulnerable way. (Which isn't as uncommon as you'd think in homebrew crypto.)
If you're using HMAC, length extension attacks are a moot point. There's a reason 'tptacek always recommends HMAC for symmetric authentication.
SHA-224, SHA-384, SHA-512/224, and SHA-512/256 are not vulnerable to length extension attacks.
BLAKE2 is not vulnerable to length-extension attacks. It's also at least as secure as SHA2, but faster than MD5. SHA3 is at least as secure as BLAKE2, but is significantly slower in software.
Thus, the recommendations are:
- BLAKE2
for speed and security
- SHA-512/256
if you want speed, length-extension attack resistance, and arbitrary standards compliance
- SHA3-256
if you care more about security and what the FIPS authors think than speed
- SHA-384
if you're concerned about backwards compatibility but don't want to accidentally cause
junior developers that poorly mimic your designs to introduce LEAs into their code
- Any other SHA-2 family hash function
if you're not interested in all of this nuance and want something
guaranteed to be secure for the next few years that is widely implemented
Of course, there should be a huge asterisk with this list: If you're not a crypto expert,
you shouldn't be making this decision. Just stop using SHA1.
It's also worth noting that Marc Stevens-- hash function breaker extraordinaire-- disagrees with my recommendation because BLAKE2 isn't a {NIST,FIPS,ISO,whateverStandardsBodyYouTrust}-approved hash function, and for better or worse, believes strongly in reinforcing public trust in standards organizations. https://twitter.com/realhashbreaker/status/11283816001468948...
He has a point in general, but in this specific case, I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous.
Also, standards bodies have a nasty habit of digging in their heels on their mistakes, instead of issuing new guidance in response to research. See also: WPA3 and Dragonfly vs SPAKE2-EE or OPAQUE.
For a higher-level example, look at the failures baked into the JOSE standards (JWT, etc.) versus PASETO.
Fun fact: If you take JOSE and replace JSON with CBOR, without fixing any of the protocol security problems, you get COSE... which reared its ugly head in W3C's WebAuthn standard. Bad standards never die.
Until we get a standards committee that isn't garbage, I don't entirely agree with Marc's appeal to faith here.
While NIST et al. certainly do a better job at deciding on primitives than self-styled post-2010 cypherpunks (y'know, the ones that try to cascade a bunch of ciphers together in case one is broken but then use CRC32 for mixing files into the encryption key?), their failure to correct (let alone learn from) their mistakes and update recommendations in a timely manner is a problem that can't be dealt with through blind adherence to whatever they publish.