That's not how I would put it. Existing protocols that use full-width SHA-2 aren't inherently suspect for doing so, but new designs that use SHA-2 directly might benefit from doing so. It's worth remembering that most uses of SHA-2 in real protocols occur in MACs and PRFs, where length extension either isn't a problem or is addressed specifically.

Another way to look at it is, not needing HMAC is a feature of SHA-3.

In any case: SHA-2 --- in any of its variants --- remains strong. JP Aumasson, one of the Blake2 designers, is fond of saying that SHA-2 will probably never be broken algorithmically.

Using a truncated SHA-512/256 also has the advantage of being considerably faster than SHA-256 on 64-bit CPUs. The performance difference is close to 50%. As such, I see no reason to use SHA-256 for anything[1], you're better off just using SHA-512/256 as the net storage is the same as well (32-bytes).

[1]: Assuming you're running on a 64-bit platform...

For hashing large data, yes. For password derivation schemes or hash trees, no. SHA512 is only faster per byte because the block size is larger. SHA256 has faster rounds.

If you're using SHA-anything for hashing passwords you're doing it wrong.

Industry standards like PBKDF2 use hash functions like SHA internally.

Or design your protocols to be safe from length extension attacks in the first place.

Can you please explain?

EDIT: I realized you were asking about "design your protocols against length extension", not "what is length extension". Sorry. Ignore this, but I'll leave the response for anyone else who is curious

---

SHA-{1,2} are vulnerable to length extension attacks, because of the way their Merkle-Damgard construction works. Basically, if you have the result HASH(X), you can calculate HASH(X+P), knowing only 'HASH(X)', without knowing 'X' itself. This is problematic because it means you can effectively "extend" some cryptographically hashed data with an arbitrary suffix.

You can immunize SHA-2 in one of two ways to a length extension attack:

- Truncate the hash value. For example, use SHA-512, but truncate the result to 256 bits (this is called "SHA-512/256"). This works because the output of your HASH function which is 256-bits, cannot be reused as the initial starting state for a new round of HASH (e.g. SHA-512 needs a 512-bit starting value, but the output is only 256, so this makes it impossible)

- Although it is not standard SHA-2 anymore, you can use a trick from Neils Ferguson and John Kelsey (from 2001!) to immunize it -- simply XOR a constant into the final block round before running the final compression function. Unfortunately this suggestion was not adopted for SHA-2: http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-commen...

Alternatively just use a modern hash design like BLAKE2, SHA-3, or a number of others -- these avoid the entire problem. I'd suggest just sticking to one of those two.

I object to the notion that SHA-3 and Blake2 are "modern" hash functions and that SHA-2 isn't. SHA-2 remains a first-line hashing recommendation among crypto designers. The Noise protocol framework, for instance, includes it, as does Nacl; the authors of both of these systems had hashes available that didn't have length extension.

If I had to rank those three hash functions, SHA-2 wouldn't be in last place.

E.g. Use an HMAC construction.

Some people don't understand crypto. That's where SHA-3 could save them.

FTFY: s/Some/Most/