On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2).

Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster), and it's the one with the longest track record, while the Blake-family and SHA3 are fairly new. It's also widely supported nearly everywhere. All that makes truncated SHA-512 a sane default.

> Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster)

https://twitter.com/KeccakTeam/status/834789451708628995

> It's also widely supported nearly everywhere

This is true for the non-truncated variants, but I am not aware of any protocol that uses the truncated ones.

I will agree with the "longest track record" however, this is an important part.

If you are free to choose a hash function, you are free to truncate SHA-512. Truncated SHA-512 is secure, there is no need to wait to see it used in a standardized protocol to increase confidence in its security.

Creating a truncate(SHA-512, 256) out of regular SHA-512 is trivial, so it true that it is widely supported nearly everywhere.

This is wrong, SHA-512/256 is not the same as calculating the output of SHA-512 and then taking the first 256 bits of it, there are some differences between them such as different IVs that would make the outputs also different.

Yes, sorry. You need to overwrite the initial value (H0) too, in the constructor. You can do that if you can touch the equivalent of the private member variables.

    SHA-512/256 may be used to hash a message, M, having a length of 𝓁 bits, where 128 0 ≤ 𝓁 < 2.
    The algorithm is defined in the exact same manner as SHA-512 (Sec. 6.4), with the following two exceptions:
    1. The initial hash value, H(0), shall be set as specified in Sec. 5.3.6.2; and
    2. The 256-bit message digest is obtained by truncating the final hash value, H(N), to its left-most 256 bits.

(from §6.7 in http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4....)

EDIT: I trust 'tptacek (in sibling comment) that if there is no chance of protocol confusion, there is no advantage to the different initial value.

This only matters if there's an existing protocol that uses truncated SHA-2 you need to interoperate with (and your premise is there is not).

There is no functional advantage to having a different IV for SHA-2 5-2/256.

Yup, this looks like it's a cross-domain protection.

Sure, but if you care about domain separation, you can't rely on the IV anyways.

> On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2).

Unless you are doing hash trees, in which case SHA-512 is slower than SHA-256, and length extension is not possible.

Point is there isn't and shouldn't be a blanket solution.

It is one most scrutinized hash function, for which no flaw is known. While no flaw is known for SHA-3 and many other hash functions and some might even say that likelihood of finding flaws in them is lesser than SHA-2, none has been analyzed by that many people for that long.