Why SHA-512/256 when we already have SHA-384?

Question

Both of them are just SHA-512 with different IV's and truncation. What's the point of having 2 of them? (Actually we have 3 of them as SHA-512/224 is the exact same thing.)

Answer 1

The truncated versions of SHA2 are introduced in 2005 and in the Cryptographic hash Workshop, in 2005, Kelsey listed the reasons as;

• Interoperability and security reasons
• Need drop-in replacement for SHA1 (MD5)
• Have unbroken hashes of wrong size
  • ECDSA/DSA key sizes
  • File and protocol formats

Though not mentioned by Kelsey or any other NIST document, the truncation also helps to mitigate from the length extension attack of the SHA series that is due to the Merkle-Damgård construction's architecture problem.

Using different IV enables the domain separation that enables us to have two different random oracles ^*. It makes sure that the truncated versions have different results. With the domain separation $$\operatorname{SHA-224}(m) \neq \operatorname{SHA-256}(m)|_{224}$$ where $|_{224}$ is the truncation

• What's the point of having 2 of them

  • If you have an already implementation that uses SHA-256 and you want to mitigate from the length extension attack then SHA512/256 is a good choice. Also, it possibly may increase attack strength.

  • Also, when you need only 256 but hash output, if you use the SHA512/384 you need to trim that yourself. Not a good idea in the case of programming and in the case of security since you are using the same random oracle.

  • The ECDSA/DSA key sizes: ECDSA-384 signing SHA512/384 is a good choice especially for 64-bit devices since SHA512 is designed for 64-bit.

  • Someone tried to use SHA512 and has problems with TLS 1.2. if you are adopting ECDSA-384 signing SHA512/384 is a good choice as above.

  • For SHA512/224 and simply for 224-bit usage is due to the Triple-DES security, $112 \cdot 2 = 224$. There is a very extensive answer for this by Fgrieu SHA-224 Purpose.

---

_{^*A random oracle is like a kind of hash function and the same concept applies to hash functions.}

Answer 2

SHA-512 may be faster (i.e. use fewer CPU cycles) than SHA-256 on 64 bit systems as it uses a word size of 64 bits rather than the 32 bit word size used for SHA-256. Because of this, it uses approximately a third fewer rounds per byte.

Note that SHA-256 nowadays can be supported by Intel's SHA-extensions (which also may be implemented on AMD CPU's), which may give back the advantage to SHA-256. Note as well that SHA-512 variants also have a larger block size, so I guess that SHA-256 variants could still be faster for small messages - even without CPU support.

---

Apart from the output size, the mixing functions of SHA-256 and SHA-512 differ somewhat, if just for the different word size. The algorithm construction is more or less the same though, with the same underlying security functions. Both hashes are considered secure though, so it is unclear if the SHA-512 algorithm adds much security over SHA-256, if any.

---

Having one implementation with different initialization vectors can of course also reduce code size, although it is questionable why any size-limited system would choose to use SHA-512 variants in the first place.

---

Security wise the protection against length extension attacks - as mentioned in the other answer - may also play a role. This is specific to keyed hash functions though (or, more precisely, creating hash values from a known hash value over unknown data). Note that HMAC already provides resistance against length extension attacks, which is why I would not consider it a main issue.

---

Quite a lot of libraries do not support the SHA-512/256 and /224 variants. And to be honest, outside of the slight performance benefit, I don't see too many use cases for them. I don't see many protocols specify them and knowledge of these variants seems limited.