[wongarsu]

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.

[snakeanus]

> 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.

[wolf550e]

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.

[snakeanus]

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.

[wolf550e]

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.

[tptacek]

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.

[baby]

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

[tptacek]

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

[kobeya]

> 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.