SHA-384: Truncated SHA-512 and Why the Truncation Helps
SHA-384 is SHA-512 run with a different initial state and truncated to 384 bits, giving 96 hex characters. Because output is shorter than the internal state, it is immune to the length extension attack that affects SHA-256 and SHA-512.
At a glance
- Digest size
- 384 bits
- Hex characters
- 96
- Block size
- 1024 bits (128 bytes), 64 bit words, 80 rounds
- Standard
- FIPS 180-4, defined as SHA-512 with a distinct initial hash value and truncated output
- Broken for collisions
- No. No practical attack on the full function
- Safe for password storage
- No. Use a memory-hard password hash such as Argon2id, scrypt or bcrypt
- Available in the generator
- Yes, plus HMAC-SHA-384 when a secret is supplied
In detail
SHA-384 is not a separate design. It runs the SHA-512 compression function over 1024 bit blocks with 64 bit words, but starts from a different set of eight initial constants and then discards the last 128 bits of the final state. The different starting constants matter: without them, a SHA-384 digest would simply be a prefix of the SHA-512 digest of the same input, and the two functions would be trivially related.
The truncation buys a real property. Length extension works because the digest of a Merkle-Damgard hash is the complete internal state, so an attacker can resume hashing from it. SHA-384 publishes only 384 of 512 state bits, so there is nothing to resume from without guessing the missing 128 bits. SHA-256 and SHA-512 do not have this protection; SHA-384 and SHA-512/256 do.
In practice you meet SHA-384 inside TLS. Cipher suites ending in SHA384, such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, use it for the handshake pseudorandom function rather than as a message digest. It is also the paired hash for the P-384 elliptic curve, where matching hash strength to curve strength is the convention, and it appears in higher assurance certificate profiles.
As a general purpose file hash it is an odd choice. It produces 96 hex characters, which is unwieldy in filenames and manifests, and it gives no meaningful security advantage over SHA-256 for any threat that exists. Pick it when a protocol, a curve or a compliance profile asks for it, not because more bits feel safer.
Its speed profile is worth knowing: on 64 bit hardware without SHA extensions it is typically faster than SHA-256 on long inputs, because it processes 128 byte blocks with 64 bit arithmetic. On 32 bit hardware it is slower. Either way it is far too fast for password storage. Use Argon2id, scrypt or bcrypt for passwords; ToolBox does not offer such a tool.
Examples
input: ""
38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf
63f6e1da274edebfe76f65fbd51ad2f14898b95b
input: "abc"
cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a
43ff5bed8086072ba1e7cc2358baeca134c825a7Shown wrapped for readability. The real digest is 96 unbroken hex characters.
SHA-384("abc") starts cb00753f...
SHA-512("abc") starts ddaf35a1...
Different initial constants, so the two share no prefix even
though they run the same compression function.Things that catch people out
- Do not truncate a SHA-512 digest yourself to get SHA-384. Cutting SHA-512 to 384 bits gives a different value from SHA-384, because SHA-384 changes the initial state too.
- A cipher suite name ending in SHA384 does not mean your data is hashed with SHA-384. It names the handshake and pseudorandom function, and with an AEAD cipher such as AES-GCM the record integrity comes from the cipher, not from that hash.
- 96 hex characters is long enough that it gets wrapped by terminals and email clients. When comparing two SHA-384 values by eye, paste both into the Verify tab instead; a wrapped character is easy to miss.
- SHA-384 is not slower than SHA-256 in the way people assume, so choosing SHA-256 purely for speed on a 64 bit server is often measuring nothing.
Try it: Hash Generator
Paste text or drop a file and get every digest at once, in hex or Base64, with a verify tab for comparing an expected value against what you actually have.
Hash Generator
LOCAL · Browser-OnlyGenerate MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512, Keccak-256, CRC32, and HMAC hashes from text or files
MD5 is cryptographically broken and should not be used for security purposes. Use SHA-256 or SHA-512 instead.
Related Hash algorithms
All hash algorithms →SHA-512: 512 Bit Digests and 64 Bit Word Arithmetic
SHA-512 outputs 128 hex characters using 64 bit words and 1024 bit blocks. Why it can beat SHA-256 on 64 bit hardware, and where the extra width is pointless.
SHA-256: The Default Choice and How It Is Used
SHA-256 gives a 64 character hex digest with no practical collision or preimage attack. Where it belongs, where it does not, and its length extension flaw.
HMAC-SHA-384: 384 Bit Tags and the 128 Byte Block Size
HMAC-SHA-384 gives a 96 character tag over a 128 byte block. Where JWT HS384 and TLS use it, and why the key length threshold is different.
SHA3-256: The Sponge Construction and How It Differs From SHA-256
SHA3-256 gives the same 64 hex characters as SHA-256 from a completely different construction. No length extension, different failure modes, FIPS 202.
SHA3-512: Maximum Sponge Capacity and When to Choose It
SHA3-512 outputs 128 hex characters and holds back 1024 bits of capacity, halving throughput versus SHA3-256. What that buys and when it is worth it.
Keccak-256: Ethereum's Hash and Why It Is Not SHA3-256
Keccak-256 uses the original Keccak padding, not the FIPS 202 padding. Same 64 hex characters as SHA3-256, completely different values. Why Ethereum uses it.
Tools for this
- Hash Generator Free online hash generator - generate MD5, SHA-1, SHA-256 hashes from any input text