up:: Classical Cryptography MOC

SHA-384

SHA-384 is the 384-bit member of the SHA-2 family of cryptographic hash functions, standardized by NIST in FIPS 180-4, and it turns an input of any size into a fixed 384-bit digest that acts as a tamper-evident fingerprint. It is the high-assurance hash of the SHA-2 family, and CNSA 2.0 requires SHA-384 or SHA-512 for U.S. national-security systems at every classification level. It survives the quantum transition. The strongest known quantum attack on it, Grover’s algorithm, only gives a square-root speedup on preimage search, which drops its effective preimage strength toward about 192 bits while leaving collision resistance near 192 bits. That is the opposite of what happens to public-key algorithms like RSA and ECDH, which Shor’s algorithm breaks outright. SHA-384 is not structurally broken, so it carries forward as a keeper, and it is the specific digest NIST’s most conservative authority points to for the work that has to hold for decades.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

The short version:

• SHA-384 is a hash function, so it rests on output size, not on the factoring or discrete-log math that quantum computers demolish.
• It belongs to the 64-bit branch of SHA-2, sharing internals with SHA-512. It is essentially SHA-512 run with different starting constants and truncated to 384 bits, which processes data in 1024-bit blocks over 80 rounds.
• Grover’s algorithm gives only a quadratic speedup on preimage search, which halves the preimage margin. SHA-384 goes from 384-bit to about 192-bit preimage strength and stays far out of reach.
• Collision resistance was already about 192 bits classically because of the birthday effect, and realistic quantum collision attacks buy little to no practical advantage, so the collision side is barely touched.
• CNSA 2.0 keeps hashing in the SHA-2 family and requires SHA-384 or SHA-512 for U.S. national-security systems, which is the clearest signpost that SHA-2 hashing survives the quantum era and that SHA-384 is the high-assurance step.
• The move worth making is raising hash policy to SHA-384 for high-assurance and long-retention workflows, not replacing SHA-2 wholesale.

What is SHA-384?

SHA-384 is a 384-bit cryptographic hash function in the SHA-2 family, published by NIST as part of the Secure Hash Standard in FIPS 180-4. A hash function takes a message of arbitrary length and deterministically compresses it into a fixed-length output called a digest, and a cryptographic one is built so the digest behaves like a fingerprint: the same input always gives the same digest, a different input almost always gives a different digest, and you cannot run the process backward to recover the input. SHA-384’s digest is 384 bits, written as 96 hexadecimal characters.

The security of SHA-384 is usually described through three properties, all of which it is designed to provide:

1. Preimage resistance. Given a digest, you cannot feasibly find any input that hashes to it. This is what protects a stored hash of a secret.
2. Second-preimage resistance. Given one input, you cannot feasibly find a different input with the same digest. This protects a signed or published file from being swapped for another that hashes identically.
3. Collision resistance. You cannot feasibly find any two different inputs that share a digest at all. This is the property that certificate signatures and content-addressing lean on.

SHA-384 belongs to the 64-bit branch of SHA-2, which sets it apart from SHA-256 on the 32-bit branch. Internally it is closely related to SHA-512: it uses the same 1024-bit block size, the same 64-bit word size, the same 80-round compression, and the same round logic, differing in two ways only. It starts from a distinct set of initial hash values, and it truncates the final 512-bit state down to 384 bits of output. That truncation does real security work, because it removes the length-extension weakness that bare SHA-512 carries. It is a hash function and nothing else. It is not an encryption algorithm, it is not a public-key primitive, and it is not a signature scheme on its own, though signatures and message authentication codes are built on top of it.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015 (SHA-384: 1024-bit block, 64-bit word, 384-bit digest, 80 rounds, derived from SHA-512 with distinct initial values and truncation), csrc.nist.gov/pubs/fips/180-4/final.

How does SHA-384 work?

SHA-384 uses the Merkle-Damgard construction, which turns a fixed-size compression function into a hash that accepts any length of input by chaining the compression over the message block by block. The process runs in a fixed sequence:

1. Padding. The message is padded so its total length is a multiple of 1024 bits, and the original length is encoded into the final bits of the padding. This length-encoding is part of what makes the construction resist certain forgery tricks.
2. Blocking. The padded message is split into 1024-bit blocks.
3. Chaining. SHA-384 maintains a 512-bit internal chaining state, initialized to eight fixed 64-bit constants that differ from SHA-512’s. Each 1024-bit block is fed into the compression function together with the current state, and the output becomes the new state for the next block.
4. Compression. For each block, the compression function runs 80 rounds. It first expands the 1024-bit block into a longer message schedule, then mixes it into the state using modular addition on 64-bit words, bitwise XOR, logical selection functions, and right-rotations, with a different fixed round constant at each round.
5. Output. After the last block, the final 512-bit chaining state is truncated to its leading 384 bits, and that is the digest.

The combination of nonlinear logical functions, rotations, and the expanding message schedule is what gives SHA-384 the avalanche property: flipping a single bit of the input changes roughly half the output bits in an unpredictable way, so the digest reveals nothing about how close two inputs are.

One structural point separates SHA-384 from bare SHA-512. Because SHA-384 truncates its 512-bit state to 384 bits, an attacker never sees the full internal state in the output, which closes the length-extension attack that bare SHA-512 and SHA-256 are open to. That makes SHA-384 usable more directly than SHA-256 in some constructions, though HMAC remains the standard way to build a keyed authenticator regardless. That property is about the construction, and it has nothing to do with quantum computing.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

What is SHA-384 used for?

SHA-384 sits in the higher-assurance layer of integrity and trust work, where an organization wants more margin than SHA-256 without leaving the SHA-2 family. Its common jobs:

1. High-assurance certificate signatures. TLS and other X.509 certificates in national-security, government, and defense ecosystems are frequently signed over a SHA-384 digest, which is what binds the certificate’s identity to the issuing authority at the assurance level those systems require.
2. Digital signature preprocessing. A digital signature is computed over a small fixed-size digest, not the whole document, and SHA-384 produces that digest where the surrounding signature scheme is chosen for strength.
3. Firmware and secure-boot integrity. Root-of-trust and secure-boot workflows use SHA-384 to fingerprint firmware images whose integrity guarantee has to hold for the operational life of the device.
4. Software supply-chain provenance. Package digests, release validation, and artifact verification in high-assurance pipelines use SHA-384 where a wider margin is warranted.
5. Message authentication. HMAC-SHA-384 authenticates high-value API traffic and trust metadata, proving both that a message is intact and that it came from someone holding the shared key.
6. Long-lived audit and compliance records. Integrity chains that must remain trustworthy for many years use SHA-384 so the digest strength does not become the weak point over a long retention horizon.

The pattern across all of these is that SHA-384 is the high-assurance integrity-and-trust workhorse. It rarely protects confidentiality directly. It proves that data is what it claims to be, at a margin sized for the highest-value and longest-lived records, and that difference shapes its quantum exposure.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

Is SHA-384 quantum-vulnerable?

No, not in the way public-key cryptography is. SHA-384 is not structurally broken by a quantum computer, because it does not rest on a hidden mathematical structure the way factoring or the discrete logarithm do. Shor’s algorithm, the quantum attack that actually breaks cryptography, solves those number-theoretic problems and does not apply to a hash function. The only relevant quantum pressure on SHA-384 comes from Grover’s algorithm, and Grover only weakens, it does not break. Walking the two security properties that matter:

1. Preimage resistance takes a square-root hit. Grover searches an unstructured space of N possibilities in about √N steps instead of up to N. Finding a preimage for a 384-bit digest is a search over roughly 2^384 inputs, which Grover reduces to about 2^192 work. So SHA-384’s effective preimage strength drops from 384 bits toward about 192 bits, which is a margin no foreseeable machine threatens.
2. Collision resistance is barely touched. Collision-finding was never a 2^384 problem to begin with. The birthday effect already lets a classical attacker find a collision in a 384-bit hash in about 2^192 work, so SHA-384 offers roughly 192 bits of collision resistance even today. Quantum collision-finding algorithms exist, but in realistic cost models that account for the enormous memory and hardware they require, they offer little or no practical advantage over the classical birthday attack. The collision side of SHA-384 looks about the same after quantum as before.

NIST states the general case plainly: Grover’s quadratic speedup on unstructured search “does not render cryptographic technologies obsolete,” but “can have the effect of requiring larger key sizes, even in the symmetric key case,” and for hash functions the remedy is a larger output rather than a new algorithm. The practical read is that SHA-384 keeps roughly 192 bits of security on both counts, which is a very wide margin, and it is already the larger-output answer for anything SHA-256 feels tight for.

Sources: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final; NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

Why is “quantum breaks all cryptography” wrong for hashes?

The claim is wrong because it collapses two very different halves of cryptography into one, and quantum computers do opposite things to each half. SHA-384 sits firmly on the surviving side. The distinction the headline erases:

1. Public-key cryptography is the catastrophe. RSA, Diffie-Hellman, ECDH, and the elliptic-curve signature schemes all rest on factoring or discrete logarithms, and Shor’s algorithm solves both efficiently. Those algorithms stop working entirely, which is why they need brand-new post-quantum replacements like ML-KEM and ML-DSA.
2. Hash functions and symmetric ciphers mostly survive. SHA-384 and its cousins face only Grover’s algorithm, which halves the preimage margin and barely touches collision resistance. The fix, where one is even needed, is a longer digest, and SHA-384 already carries one.

So a more accurate headline is that quantum computers break the public-key half of cryptography and dent the hash-and-symmetric half. Repeating “quantum breaks everything” is worse than imprecise, because it aims remediation at the wrong layer. Time and money spent worrying about replacing SHA-384 is time and money not spent on the urgent work, which is replacing the vulnerable public-key algorithms that sign and protect the data around it.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016 (public-key algorithms fall, symmetric and hash algorithms need larger sizes), csrc.nist.gov/pubs/ir/8105/final.

How does SHA-384 compare across the SHA-2 family?

SHA-384 is the high-assurance middle-to-upper option in a family where nothing is broken. The members are not a broken-versus-safe set. They are a graduated set of safe options, and the choice is a policy decision by use case. The comparison across the SHA-2 family:

Hash	Branch	Block size	Output size	Effective quantum preimage strength	Collision strength	Verdict
SHA-224	32-bit	512-bit	224-bit	~112-bit	~112-bit	Retire in favor of SHA-256 for new work
SHA-256	32-bit	512-bit	256-bit	~128-bit	~128-bit	Safe, keep for most integrity and signature work
SHA-384	64-bit	1024-bit	384-bit	~192-bit	~192-bit	High-assurance and long-retention default; required by CNSA 2.0
SHA-512	64-bit	1024-bit	512-bit	~256-bit	~256-bit	Maximum margin, and often faster on 64-bit hardware
256	64-bit	1024-bit	256-bit	~128-bit	~128-bit	64-bit-branch speed with length-extension resistance

The effective preimage numbers come from halving the output under an idealized Grover attack, and the collision numbers from the birthday bound of about half the output. SHA-384’s roughly 192 bits on both counts is a very wide margin, which is exactly why it is the reach-for hash when the assurance or the data lifetime genuinely demands more than SHA-256. Moving from SHA-256 to SHA-384 is a policy and parameter change, not a migration to a new algorithm family, which is why it belongs in the “review and strengthen” pile rather than the “rip and replace” pile.

Sources: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final; NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

Why does CNSA 2.0 require SHA-384?

CNSA 2.0, the NSA suite that sets post-quantum algorithm requirements for U.S. National Security Systems, keeps hashing inside the SHA-2 family and requires SHA-384 or SHA-512 for national-security work at all classification levels. It does not deprecate the SHA-2 family the way it retires classical public-key algorithms. The same advisory that removes RSA and ECDH in favor of ML-KEM and ML-DSA holds SHA-2 in place and sets the required output at 384 bits or larger for its highest-assurance domain.

That choice is strong public evidence for SHA-384’s standing. When the most conservative cryptographic authority in the U.S. government treats hashing as survivable and moves the dial from 256 to 384 bits for its most sensitive systems rather than to a new hash family, it confirms two things at once: the SHA-2 design carries forward through the quantum era, and SHA-384 is the specific high-assurance step for the workflows that need the most margin. SHA-384’s roughly 192-bit quantum-adjusted margin is the reason it is a comfortable choice for exactly the decades-long, high-value integrity CNSA 2.0 governs.

Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” CSA U/OO/194427-22, September 2022, nsa.gov.

Common misconceptions

1. “Quantum computers will break SHA-384.” They will not. The only relevant quantum attack is Grover’s, which halves the preimage margin to about 192 bits and barely touches collision resistance, both far out of reach.
2. “SHA-384 needs to be replaced with a post-quantum hash.” It does not. There is no separate post-quantum hash family to migrate to, because SHA-384 already carries a very wide margin. The replacements are for public-key algorithms.
3. “Grover halves collision resistance the same way it halves preimage resistance.” It does not. Collision resistance was already about half the output size classically because of the birthday effect, and realistic quantum collision attacks add little practical advantage, so the collision side is roughly unchanged.
4. “SHA-384 is just SHA-512 with a shorter output, so it is weaker.” It is derived from SHA-512 with different initial values and truncation, but the truncation is a feature, because it removes the length-extension weakness that bare SHA-512 carries.
5. “SHA-256 and SHA-384 are a broken-versus-safe pair.” Both are safe. SHA-384 simply carries a wider margin, which matters for high-assurance and decades-long integrity, not for ordinary integrity checks.
6. “If a certificate is signed with SHA-384, a quantum computer forges it by finding a collision.” No. A quantum attacker breaks the RSA or elliptic-curve signing key with Shor’s algorithm and signs any digest at will, so the hash strength is not what protects the signature.

Questions people ask

Is SHA-384 quantum-safe? Yes. It faces only Grover’s algorithm, which halves its preimage margin to about 192 bits and leaves collision resistance near 192 bits, both very wide margins. It is not the kind of primitive a quantum computer breaks, and NIST’s most conservative authority requires it for national-security work.

Do I have to replace SHA-384 for post-quantum security? No. SHA-384 is one of the primitives that carries forward through the transition. The post-quantum replacements target public-key algorithms like RSA and ECDH, not hash functions. SHA-384 is often the destination when raising hash policy above SHA-256.

What is the difference between SHA-384 and SHA-512 for quantum? Both survive. Grover halves the preimage margin of each, so SHA-384 keeps about 192 bits and SHA-512 keeps about 256 bits. SHA-384 is the CNSA 2.0 high-assurance requirement, and it also resists length extension because it truncates its state, while bare SHA-512 does not.

Why does CNSA 2.0 require SHA-384 instead of a new hash? Because SHA-2 hashing survives the quantum transition, so there is no new hash family to move to. NSA simply raised the required output size to 384 bits for its highest-assurance domain, which is a parameter change rather than an algorithm replacement.

Is SHA-384 approved by NIST and required by any mandate? Yes. SHA-384 is specified in NIST’s Secure Hash Standard, FIPS 180-4, and CNSA 2.0 requires SHA-384 or SHA-512 for U.S. national-security systems at all classification levels.

If SHA-384 is safe, what should the migration actually focus on? The public-key layer: the RSA and ECDH key exchanges and the ECDSA and RSA signatures that quantum computers break. Replacing those with post-quantum standards, with the agility to swap algorithms and hash sizes cleanly, is where the effort belongs.

---

Everything here is the map, given freely. When your team needs its own cryptography sorted into what survives the quantum transition and what has to move, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.