SHA-512/256 is the second resort, and it’s the 512 bit variant of SHA-2 truncated to 256 bits (SHA-384 is similar). Generally any SHA followed by a relatively large number is actually a variant of SHA-2.
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).
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.
> I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous.
I think you mean "de facto", unless you think NIST is going to amend SHA-3 at this point to designate BLAKE over Keccak.
As someone on the sidelines, having read the linked Twitter discussion you had with Marc Stevens your summary of it honestly seems a bit disingenuous.
You mention speed prominently, but fail to mention his counterargument that raw hash speed isn't relevant for most applications.
In practice hashing speed is drowned out by other things, you're not going to have "Android/iOS devices" (as you bring up) hashing GBs of data as a common use-case, and even if you did the cycles/byte for the hash are nothing compared to other things.
For applications where hashing speed does matter (e.g. some server needing to batch-hash things) you have the option of buying hardware-accelerated SHA-256 to get on the order of 30% faster than BLAKE: https://bench.cr.yp.to/results-hash.html
Then as you note downthread your criteria of "at least as secure" only takes into account "known attacks". The absurd logical conclusion of that criteria taken at face value is that we'd all be better off if we each used our own bespoke hash function, since cryptanalysis would never be able to keep up.
Or, in other words, if the algorithm that became SHA-1 hadn't been picked by NIST in 1995 it would be a viable 160-bit hash function today, since there would likely be no known attacks against it, as it would have been obscure enough that nobody would have bothered with it.
So the criteria for a "secure" hash must consider some balance of its algorithm, as well as (or more importantly) the cumulative amount of attention cryptographers have spent on it.
> The absurd logical conclusion of that criteria taken at face value is that we'd all be better off if we each used our own bespoke hash function, since cryptanalysis would never be able to keep up.
The reason this "logical conclusion" sounds so absurd is that your reasoning here is absurd.
What matters isn't "cryptanalysts haven't published an attack", what matters is "cryptanalysts tried and failed to attack the design".
If you conflate the two, you will end up confused.
A reductio ad absurdum is always going to be absurd if taken at face value, but that doesn't mean the underlying point it's making isn't valid.
Obviously I'm not saying that BLAKE hasn't gotten any analysis. It was a SHA-3 finalist, it's been looked at by a lot of smart people.
I am saying it's a continuum, and it's safe to assume SHA-2 has gotten a lot more eyeballs & man hours by now. Both due to its age, and due to its widespread production use as a NIST standard.
Is that a trite point? Yes, but one you managed to omit in your long summary of a Twitter exchange with a SHA-1 researcher, which is why I'm pointing it out. You're seemingly treating "analyzed" as a boolean property.
It's trite because it should go without saying, but one you managed to selectively omit when summarizing a Twitter discussion. That makes you seem disingenuous.
It's clear from anyone who reads that Twitter discussion that the thrust of Marc's point is not that we should be "reinforcing public trust in standards". To summarize the discussion in those terms amounts to attacking a strawman.
"Marc Stevens wants to reinforce the public trust in standards, especially among non-experts" isn't an uncharitable summary of this conversation.
> That makes you seem disingenuous.
If I'm mistaken about the point he's defending, it's not an act of dishonesty.
Given that he at multiple points agreed with my arguments that standards bodies make dumb mistakes and yet continued to double down on "we should just follow standards anyway" without caveat, there aren't many alternative interpretations that I'm aware of.
If I still seem disingenuous, it might be that you want me to seem that way. In which case, there's no point in either of us continuing to participate because it has ceased to be about security and instead has become a discussion of ego, which I'm frankly uninterested in.
Actually, I did add caveats and do recognize that not all standards are equally important. In the tweets you link I'm talking about secure standards, as in standards that are actually considered secure.
Rather that it is better to promote to work through standards as a community as opposed to your way of where individuals promote their pet primitives.
Standards serve a role as a focal point: the benefit of being big targets, getting a lot of scrutiny and easier for non-experts to find out if somebody found security issues.
I'm one of the co-author of the SHA-1 cryptanalysis paper. I fully agree with Marc Stevens's: you should not be using Blake2, but SHA2 or SHA3. If speed is an issue, taking reduced step SHA3 (KangarooTwelve) will do the job.
Has KangarooTwelve received more analysis than BLAKE2? Or are both recommendations morally equivalent in the context of standardization and confidence in security margins?
To be clear: I agree with Marc in general, but there are exceptions where I disagree with Marc's "only use {FIPS,NIST,etc.}-approved crypto":
* I prefer Ed25519 over foot-bullety ECDSA (i.e. before RFC 6979).
* I prefer to never use RSA at all.
* I prefer XChaCha20-Poly1305 over AES-GCM, since the former is always constant-time without requiring specialized hardware and you have a negligible chance of nonce misuse even after an absurd number of messages.
* I prefer Argon2id and scrypt over PBKDF2 for key stretching.
* I prefer Argon2id and bcrypt over PBKDF2 for password storage.
* I prefer BLAKE2 over SHA-256, especially when length extension attacks are within the threat model of the protocol being discussed. SHA3 is good. Most SHA2 hash functions are fine (as long as they're not being used stupidly). But BLAKE2 is not only faster, thanks to libsodium, it's more readily available to developers than SHA3 (which, like AES, is only performant with specialized hardware circuits in software that takes advantage of said circuits).
None of the algorithms I've mentioned above are random pet projects by hobbyists.
To resolve this impasse, what needs to happen is: Standards bodies (NIST, FIPS, ISO, etc.) need to stop digging their heels in on sunk-cost fallacies and give at least some of these algorithms a fair consideration. Then one of two things will follow:
1. They'll be found to be as secure as the cryptographers who have studied them already believe, and therefore appropriate for standardization.
2. New attacks will be found, and the state of the art can be moved forward.
And this trend of cryptography towards requiring specialized hardware to be fast and secure? I oppose it wholeheartedly.
