SHA-384 vs SHA-512: Two Algorithms, One Code Path

If you've configured a TLS server, you've seen cipher suites like ECDHE-ECDSA-AES256-GCM-SHA384. The "SHA384" here is the hash function that protects the handshake. Why SHA-384 instead of SHA-256 or SHA-512? The answer touches on NSA Suite B cryptography, a brief security margin discussion, and one of the more interesting performance quirks in hash algorithms.

Why SHA-512 is fast (and why SHA-384 inherits that)

SHA-512 was designed for 64-bit processors. It uses 64-bit words internally, larger blocks (1024 bits vs. SHA-256's 512), and 80 rounds of processing per block (vs. 64 for SHA-256). On a 64-bit CPU, SHA-512 processes twice as much data per block in only 25% more rounds — net result is that SHA-512 is typically 30-60% faster than SHA-256 on 64-bit systems for hashing large data.

On 32-bit hardware the math reverses: 64-bit operations have to be emulated using pairs of 32-bit operations, making SHA-512 slower than SHA-256. But 32-bit hardware is increasingly rare in 2026.

SHA-384 inherits all of SHA-512's performance characteristics because it is SHA-512, just with different initial values and a truncated output.

What "Suite B" is and why it matters

The NSA's Suite B Cryptography was a set of cryptographic algorithm recommendations published in 2005 for protecting US government information. Suite B specifies two protection levels:

Level	Symmetric	Asymmetric	Hash
SECRET	AES-128	ECDH P-256, ECDSA P-256	SHA-256
TOP SECRET	AES-256	ECDH P-384, ECDSA P-384	SHA-384

Notice the pairing: SHA-256 with 256-bit elliptic curves, SHA-384 with 384-bit elliptic curves. The hash output size matches the curve size. This isn't a strict mathematical requirement — you could use SHA-256 with P-384 — but it provides a consistent security level across all components and avoids unnecessary truncation.

Suite B was officially replaced by the NSA's CNSA (Commercial National Security Algorithm Suite) in 2015. CNSA recommends SHA-384 across the board for both SECRET and TOP SECRET levels. The change reflects a precautionary upgrade against future cryptanalytic advances.

Practical implication: if you're working with government, military, or defense-adjacent systems and you see "SHA-384" in a requirements document, that's why. For commercial systems, SHA-256 vs. SHA-384 is essentially a stylistic choice.

Side-by-side

Property	SHA-256	SHA-384	SHA-512
Output size	256 bits	384 bits	512 bits
Block size	512 bits	1024 bits	1024 bits
Word size	32-bit	64-bit	64-bit
Rounds	64	80	80
Collision resistance	2¹²⁸	2¹⁹²	2²⁵⁶
Length-extension vulnerable?	Yes	No (truncated)	Yes
Speed on 64-bit (1 MB)	~3.5 ms	~2.5 ms	~2.5 ms
Speed on 32-bit (1 MB)	~3.5 ms	~6 ms	~6 ms

The length-extension column is interesting. SHA-256 and SHA-512 both publish their full internal state as the hash output, which makes length-extension attacks possible. SHA-384 truncates the SHA-512 state by 128 bits, which is enough to make length-extension infeasible — you'd have to guess the truncated bits. (Same idea as SHA-224, just with bigger numbers.)

For practical purposes, length-extension is rarely the right attack to worry about — HMAC is the standard defense and works with any hash function. But if you specifically need a hash function that's not vulnerable, SHA-384 has that property and SHA-256/SHA-512 don't.

Where SHA-384 shows up in the wild

• TLS 1.2 and 1.3 cipher suites — the _SHA384 variants pair AES-256 with HMAC-SHA-384 for the integrity layer.
• X.509 certificates — TLS certificates signed with ecdsa-with-SHA384 (using P-384 keys).
• Document signing — Adobe PDF signatures using ECDSA-P384 use SHA-384 for the document digest.
• JOSE / JWT — ES384 algorithm uses ECDSA-P384 + SHA-384.
• Compliance frameworks — CNSA, FIPS-140 high-assurance levels.

The bottom line

For new code where you have a free choice, SHA-256 is the broader default. It's the most universally supported, has the most hardware acceleration (Intel SHA-NI specifically targets SHA-256), and is what 90%+ of cryptographic protocols specify.

Reach for SHA-384 if:

• You're building something that needs CNSA or Suite B compliance
• You're using P-384 elliptic curve keys and want hash size parity
• You specifically need a length-extension-resistant hash without HMAC
• A standard you're implementing names SHA-384 explicitly

Reach for SHA-512 if:

• You want the largest practical security margin
• You're on 64-bit hardware and don't need the 16 extra bytes truncated
• A spec explicitly requires it