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


2 Answers 2


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.

  • $\begingroup$ "way before" boils down to a minute.. On second look, I see Keccak was about final in 2010, when the first publication of SHA-512/256 was February 2011. Thus your initial chronology was OK when we compare Keccak (rather than SHA-3) to truncated-to-less-than-384-bit variants of SHA-512. Independently: SHA-512/256 does thwart length-extension attack, but I have no reference that the rationale for it included that. In all signature applications, and HMAC, length-extension is a non issue, thus why would FIPS/NIST care? $\endgroup$
    – fgrieu
    Commented Sep 2, 2020 at 9:55
  • $\begingroup$ Yes, for signature it is not an issue. $\endgroup$
    – kelalaka
    Commented Sep 2, 2020 at 10:05
  • 1
    $\begingroup$ Unless we are sure resisting the length-extension attack was a goal of SHA-512/256 and SHA-512/224 (I have no opinion), the Dr. Spock in me would stick to sure facts and write: SHA-512/256 and SHA-512/224 where introduced while SHA-3 was in maturation. Contrary to the earlier SHA-256 (and to a degree SHA-224), these new constructions resist the length-extension attack. $\endgroup$
    – fgrieu
    Commented Sep 2, 2020 at 10:09
  • 1
    $\begingroup$ Addition: the criteria listed in the January 2007 RFP for what became SHA-3 states as evaluation criteria: "The extent to which the algorithm output is indistinguishable from a random oracle", which includes resistance to the length-extension attack. Thus at least that was a stated goal way before the introduction of truncated-to-less-than-384-bit variants of SHA-512. $\endgroup$
    – fgrieu
    Commented Sep 2, 2020 at 10:20
  • $\begingroup$ As far as I know, NIST has never given length extension resistance as an argument for the truncated hashes. As fgrieu notes, none of the applications that NIST has for SHA-2 (unlike SHA-3) need LER. And this wouldn't be an argument for having SHA-512/256 in addition to SHA-384 anyway. Truncated SHA-512 was introduced before Keccak was selected as SHA-3. The bullet point about TLS makes no sense since the problem with SHA-512 and TLS is that TLS doesn't support SHA-512, and adding a new hash that TLS also doesn't support won't solve that. $\endgroup$ Commented Sep 2, 2020 at 20:28

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.