SHA-384 Hash Algorithm Explained: Principles, Uses, Security, and Best Practices
A detailed guide to SHA-384: how it works, what its output means, where it is used, how secure it is, and how it compares with SHA-256 and SHA-512.
SHA-384 (Secure Hash Algorithm 384-bit) is a cryptographic hash function in the SHA-2 family. It converts input data of any length into a fixed 384-bit digest, usually represented as a 96-character hexadecimal string. Compared with SHA-256, SHA-384 provides a longer output and a larger collision-resistance margin. Compared with SHA-512, it uses a similar 64-bit internal structure but truncates the final digest to 384 bits.
Need to generate SHA-384, SHA-256, SHA-512, or other SHA-family hashes quickly? Try our SHA Hash Generator.
It is important to understand what SHA-384 is and what it is not. SHA-384 is a hash function, not an encryption algorithm. It has no key, cannot be decrypted, and should not be used directly for password storage. It is best understood as a tool for integrity checks, digital signature workflows, data fingerprints, content addressing, and digest calculation inside security protocols.
1. What is SHA-384?
SHA-384 belongs to the SHA-2 family, designed by the U.S. National Security Agency (NSA) and published by the National Institute of Standards and Technology (NIST) in the FIPS 180 series. The SHA-2 family includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.
Structurally, SHA-384 is closer to SHA-512 than to SHA-256. It uses 1024-bit message blocks, 64-bit working words, and 80 compression rounds. The final output is the first 384 bits of the internal hash state.
Core SHA-384 parameters:
| Item | SHA-384 Value |
|---|---|
| Output length | 384 bits |
| Hexadecimal length | 96 characters |
| Block size | 1024 bits |
| Internal word size | 64 bits |
| Compression rounds | 80 |
| Algorithm family | SHA-2 |
Example output:
Input: "Hello World"
SHA-384: "99514329186b2f6ae4a1329e7ee6c610a729636335174ac6b740f9028396fcc803d0e93863a7c3d90f86beee782f4f3f"
Input: "Hello World!"
SHA-384: "bfd76c0ebbd006fee583410547c1887b0292be76d582d96c242d2a792723e3fd6fd061f9d5cfd13b8f961358e6adba4a"
Adding a single exclamation mark completely changes the digest. This behavior is known as the avalanche effect.
2. Core Properties of SHA-384
A cryptographic hash function suitable for security-sensitive use is expected to provide these properties:
- Determinism: the same input always produces the same output
- Fixed-length output: a short word and a large file produce digests of the same length
- Efficient computation: text, binary files, and streams can be processed quickly
- Preimage resistance: given a hash value, it should be hard to recover the original input
- Second-preimage resistance: given one input, it should be hard to find a different input with the same hash
- Collision resistance: it should be hard to find any two different inputs with the same hash
For an ideal 384-bit hash function, a generic collision attack costs about 2^192 work, while a preimage attack costs about 2^384 work. This makes SHA-384 attractive for digital signatures, certificates, long-term integrity checks, and high-value data protection.
3. How SHA-384 Works
At a high level, SHA-384 pads the message, splits it into blocks, expands each block into a message schedule, repeatedly compresses the data into an internal state, and finally outputs a truncated digest. It uses a Merkle-Damgard construction, where each block updates the hash state.
3.1 Message Padding
SHA-384 first pads the input so it can be processed in 1024-bit blocks:
- Append one
1bit to the original message - Append enough
0bits to reach the required length - Make the padded length congruent to
896 mod 1024 - Append a 128-bit field containing the original message length in bits
After padding, the total message length is a multiple of 1024 bits. Even an empty string goes through the same padding process.
3.2 Initial Hash State
SHA-384 starts with eight 64-bit initial hash values. These initial values are different from SHA-512’s initial values, which is why SHA-384 is not simply “SHA-512 cut down to 384 bits” for the same input.
3.3 Message Expansion and Compression
Each 1024-bit block is first split into sixteen 64-bit words, then expanded into eighty 64-bit message words. The expansion process uses rotate-right operations, shifts, XOR, and modular addition, ensuring that every part of the original block influences many later rounds.
The compression stage uses eight working variables and eighty round constants. Each round mixes the current state, one message word, and one round constant. After many rounds, even a tiny input change affects a large portion of the final digest.
3.4 384-bit Output
After all message blocks have been processed, SHA-384 does not output the full 512-bit internal state. Instead, it returns the first 384 bits. That is why the hexadecimal representation is always 96 characters long.
4. Common Uses of SHA-384
SHA-384 is less common than SHA-256 for everyday checksums, but it is useful in higher-assurance security contexts.
4.1 Digital Signatures
In RSA, ECDSA, EdDSA, and similar signature workflows, systems usually sign a digest or a structured value derived from a digest, not an entire large message directly. SHA-384 is often used when a higher security level is desired, especially alongside the P-384 elliptic curve.
4.2 TLS and Certificates
Modern TLS configurations and X.509 certificate chains can use SHA-384 as a signature digest algorithm. It appears in higher-security certificate policies, enterprise configurations, and systems that prefer stronger digest sizes.
4.3 File Integrity Checks
For long-lived, high-value, or integrity-sensitive files, SHA-384 provides a longer digest and a larger collision-resistance margin than SHA-256. A publisher can share a SHA-384 digest, and users can recompute the digest after downloading the file to check whether it was modified or corrupted.
4.4 Content Addressing and Data Fingerprints
Archival systems, deduplication systems, object stores, and audit logs can use SHA-384 as a data fingerprint. If the content changes, the digest changes as well, making SHA-384 useful for identifying immutable objects.
5. SHA-384 vs SHA-256 vs SHA-512
| Algorithm | Output Length | Block Size | Word Size | Hex Length | Typical Reason to Choose |
|---|---|---|---|---|---|
| SHA-256 | 256 bits | 512 bits | 32 bits | 64 chars | Strong compatibility and a general-purpose default |
| SHA-384 | 384 bits | 1024 bits | 64 bits | 96 chars | Larger security margin, often paired with P-384 |
| SHA-512 | 512 bits | 1024 bits | 64 bits | 128 chars | Longest SHA-2 output, useful when full 512-bit digests are desired |
Practical selection guidance:
- Use SHA-256 for ordinary file checks, API signatures, and general-purpose digests
- Use SHA-384 when your signature, certificate, or protocol profile targets a 384-bit digest
- Use SHA-512 when your system can comfortably store and compare the full 512-bit output
On 64-bit CPUs, SHA-384 and SHA-512 can perform well because they use 64-bit word operations. In some environments they may even be faster than SHA-256. Actual performance depends on the runtime, hardware instruction support, and implementation quality.
6. Is SHA-384 Secure?
SHA-384 is still considered suitable for modern security use. It belongs to the SHA-2 family, and there is no practical collision attack that breaks its intended security properties. Unlike MD5 and SHA-1, SHA-384 has not been retired due to real-world collision attacks.
Still, correct use matters:
- Do not treat SHA-384 as encryption; it does not hide plaintext
- Do not use plain SHA-384 directly for password storage; use Argon2, bcrypt, scrypt, or PBKDF2 instead
- Do not invent message authentication with
SHA384(secret + message); use HMAC-SHA-384 - Do not compare only a very short digest prefix unless you understand the collision risk
- Do not ignore input encoding; UTF-8, UTF-16, and other encodings produce different digests
7. HMAC-SHA-384 vs Plain SHA-384
Plain SHA-384 converts input into a digest, but it does not prove who created the message. If you need to verify that a message came from someone who knows a shared secret and was not modified, use HMAC-SHA-384.
HMAC-SHA-384 combines a secret key and a message using a standardized construction before hashing. This avoids the security problems of manually concatenating a secret and a message. It is commonly used for API request signing, webhook verification, service-to-service authentication, and secure token checks.
In short:
- SHA-384: good for public data fingerprints and integrity checks
- HMAC-SHA-384: good for keyed message authentication
8. Best Practices
When using SHA-384 in real systems, follow these practices:
- Record the input encoding clearly, such as UTF-8
- For file checks, publish the file size, algorithm name, and digest value together
- Compare the full digest string and normalize casing, spaces, and line endings where needed
- Use mature libraries instead of implementing the compression function yourself
- Use a dedicated password hashing algorithm for passwords
- Use HMAC-SHA-384 when a secret key is involved
9. Summary
SHA-384 is a practical high-strength hash function in the SHA-2 family. It outputs a 384-bit digest, commonly shown as 96 hexadecimal characters, and is well suited for digital signatures, certificate systems, file integrity checks, data fingerprints, and high-value data protection.
For general-purpose checks, SHA-256 is usually enough. When your system needs a larger security margin or must align with P-384, TLS, certificate, or policy requirements, SHA-384 is a strong choice. To calculate it online, use the SHA Hash Generator.