SHA384 is a truncated version of SHA512. But why would anyone use it? And corollary: if SHA384 is just as good as SHA512, is there any rationale in using the 512 bit version?
I am planning to use one of the algorithms to verify file integrity, so I am mainly interested in collision security.
I would be happy to hear how anyone uses the SHA2 digests in practice and why would you chose one version over the other.
The reason why SHA-512 is faster than SHA-256 on 64-bit machines is that has 37.5% less rounds per byte (80 rounds operating on 128 byte blocks) compared to SHA- 256 (64 rounds operating on 64 byte blocks), where the operations use 64-bit integer arithmetic.
The reason to change from SHA256 to SHA512 is that SHA256 needs a lot more rounds to be as secure as SHA512, so while it's not insecure, it's less secure.
SHA-384 is roughly 50% faster than SHA-224 and SHA-256 on 64-bit machines, even if its digest is longer. The speed-up is due to the internal computation being performed with 64-bit words, whereas the other two hash functions employ 32-bit words.
SHA-512 is generally faster on 64-bit processors, SHA-256 faster on 32-bit processors. (Try the command openssl speed sha256 sha512 on your computer.) SHA-512/256 sits right in between the two functions—the output size and security level of SHA-256 with the performance of SHA-512—but almost no systems use it so far.
SHA512, SHA256, SHA1, and MD5 are vulnerable to a length extension attack. SHA224 and SHA384 are not since reduced output to internal state, SHA3 is also not vulnerable. Having that in mind, SHA512 is a good cryptographic collision-resistant hash function.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With