SHA-384 hash generator

Almost nobody arrives here by choice. A cipher suite named it, a certificate was signed with it, an integrity attribute on a script tag begins sha384-, or a compliance document says 384 bits and is not interested in discussion. The good news is that there is no separate algorithm to learn — the interesting part is what the truncation does, because it is the reason SHA-384 behaves differently from the SHA-512 it is cut from.

What “truncated SHA-512” means exactly

SHA-384 and SHA-512 are the same machine. Same 64-bit words, same 1024-bit blocks, same 80 rounds, same round constants. Only two things differ, and both are small enough to print:

• The eight starting values. SHA-512 begins from the fractional parts of the square roots of the first eight primes; SHA-384 begins from the square roots of the ninth through sixteenth. Everything downstream of that diverges from the first block onward.
• The ending. The final state is eight 64-bit words either way. SHA-512 gives you all eight. SHA-384 hands over the first six — 384 bits, 48 bytes, 96 hexadecimal characters — and discards the last two.

Those two changes together are why the digests have no visible relationship. Because the starting values differ, the SHA-384 of a file is not a prefix of its SHA-512, not a suffix, and not related to it in any recoverable way. You can confirm that in ten seconds with a three-letter input.

What throwing away 128 bits buys you

Something genuine, and it is not strength in the usual sense. In SHA-256 and SHA-512, the digest is the final internal state of the algorithm. Anybody holding a digest and knowing how long the input was can resume the computation from there and produce a valid digest for that input with extra bytes glued on the end — without ever seeing the original. That is a length-extension attack, and it breaks homemade constructions of the form “hash my secret key followed by this message”.

SHA-384 withholds two of the eight state words, so an attacker trying the same trick is missing 128 bits of the machine's internals and has to guess them. That single property is why SHA-384 shows up in protocol design more often than its length alone would justify, and why a 384-bit truncation of a 512-bit function is not a pointless middle size. For ordinary file checksums none of this matters — a published checksum has no secret in it to extend — but it matters a great deal the moment a key is involved. HMAC was designed to solve the same problem a different way, and the SHA-3 family avoids it by construction, which is one of the points of SHA-2 versus SHA-3.

The headline numbers, for the compliance spreadsheet: 384 bits of preimage resistance, and 192 bits of collision resistance, because the birthday bound halves the figure that matters once a digest is acting as a document's identity. 192 bits is not an arbitrary landing spot — it is also what the P-384 curve provides, and the profiles that specify AES-256 pair it with both, which is why the three keep turning up in the same sentence.

Why TLS and certificates ask for it

Cryptographic suites are assembled from parts of matching strength, and SHA-384 is the hash that matches the heavy end. That is the whole explanation behind every place you meet it:

• TLS cipher suites. TLS_AES_256_GCM_SHA384 in TLS 1.3, and the …AES_256_GCM_SHA384 suites before it, use SHA-384 for the key schedule and the handshake transcript. The AES-256 in the name is why.
• Certificates on the strong curve. A certificate signed ecdsa-with-SHA384 over a P-384 key is the standard pairing. Worth separating from the fingerprint a tool shows you for that certificate, which is usually still a SHA-256 and describes a different thing entirely.
• Government and defense profiles. The NSA's Commercial National Security Algorithm suite specifies SHA-384 — not SHA-256, not SHA-512 — which is how it ends up in procurement documents far from any web server.
• Subresource integrity. The sha384- prefix on a CDN script tag is the same 48 bytes you see above, written in base64 rather than hex: 64 base64 characters with no trailing =, because 48 divides neatly by three. Generating a SHA-384 on a Mac covers how one digest ends up written two different ways.

When SHA-384 is the wrong choice

When nothing asked for it. If you are verifying a download, the only algorithm worth computing is the one the publisher published, and in nearly every case that is SHA-256; a 96-character digest of the same image is correct, useless and unmatchable. If you are picking an algorithm for your own manifests, SHA-256 has better tool support everywhere and the same security answer. And if there is a password involved, no member of the SHA family belongs anywhere near it — they are all fast, and fast is the flaw.

Where it is quietly useful is anywhere you will be reading digests with your own eyes, because 96 characters is nearly unambiguous. 32 characters is MD5, 40 is SHA-1, 64 is SHA-256 or SHA3-256, and 128 is SHA-512 or SHA3-512 — two candidates per length and no way to tell them apart by looking. At 96 the only other possibility is SHA3-384, which almost nobody publishes. Reading an algorithm off a checksum's length has the full table.

Checking 96 characters you were given

A good deal of SHA-384 work is comparison rather than computation: somebody sends a digest, a ticket quotes one, a reviewer asks whether the integrity attribute in a pull request is the right value. Reading 96 characters across is how that goes wrong — the eye takes the first four, the last four and trusts the middle, which is a fair check against an accidental truncation and no check at all against a value somebody chose.

When both sides are text, the Check a checksum tab does the reading for you: paste the 96 characters you were handed and they are held against the digest of whatever is in the box above, with the algorithm worked out from the length of what you pasted, so there is nothing to choose first. Watch the byte count while you do it. A string copied out of a chat window arrives with a trailing space or a folded line more often than anybody expects, and a byte of invisible difference looks exactly like a mismatch.

When the thing you need hashed is a file

This page never had an upload endpoint to call: the text goes in, it is hashed in the tab as you type, and your browser's network inspector stays empty while it works. What it cannot do is read a file — and with SHA-384 that is usually the shape of the job, because the algorithm arrives attached to a script bundle, a certificate, a signed artifact or a release image far more often than to a string you can paste into a box.

The Files tool of Rocket Hash is where that job lives. Files and folders arrive by drag-and-drop or through the add button, each file becomes a row carrying its name, the folder it came from, its size and its digest, and a chevron on the row opens every algorithm for that file at once — so nothing hangs on picking SHA-384 first, which matters here more than on most pages, because SHA-384 is typically the algorithm you discover you needed after computing something else. The 96 characters are shortened in the middle with an ellipsis to fit the row, and clicking the row copies the value whole, so nobody receives your ellipsis. Each file is read exactly once however many digests you asked for, a long run can be paused mid-file and resumed from the exact byte it stopped at, and the finished list exports as a shasum-compatible manifest.

When what you are holding is somebody else's 96 characters rather than a file of your own, the Verify tool is the shorter road: paste the value into Against a Checksum, drop the file beside it, and the verdict comes back as a green seal and a sentence instead of two long strings to read across. The algorithm is detected from the checksum you paste, and 96 characters is the one common width that names itself. Text hashing is free; the file side and the verification side are separate one-time unlocks. Verifying a download is the wider version of the same job.

Frequently asked questions

What does the 384 in SHA-384 refer to?

The length of the output in bits: 384 bits is 48 bytes, or 96 hexadecimal characters. It does not describe anything about the internals — SHA-384 uses the same 64-bit words and the same 1024-bit blocks as SHA-512, and runs the same 80 rounds. Only the starting values and the amount of the final state it publishes are different.

How do I get the SHA-384 of a file instead of text?

You cannot do it here. This box hashes text, and nothing on this site reads a file off your disk. The Files tool in the Mac app is what hashes a file — one read, every algorithm, and an exported manifest at the end if you want one. To check a file against a SHA-384 somebody published, the Verify tool takes the file and the value and answers in a sentence. Hashing a file on a Mac has the whole route.

Why is SHA-384 no faster than SHA-512 if the output is shorter?

Because the work is identical right up to the last step. Both run the same rounds over the same block size, and the truncation happens once, after the last block, by discarding two words. Timing the two on the same file gives you effectively the same number. If you want a genuinely faster digest on the same data, the variable is the word size, not the output length.

Is a sha384- integrity attribute the same value as the hex digest?

Yes — the same 48 bytes, written in base64 instead of hexadecimal. A base64 SHA-384 is exactly 64 characters and never ends in an =, while a base64 SHA-256 is 44 characters and always does. If a 64-character value contains a letter past f, a + or a /, it is base64 rather than hex — hexadecimal stops at f whether it is written in capitals or not.

Should I use SHA-384 or SHA-512?

Whichever the thing in front of you specified, because they are not interchangeable and the digests have nothing in common. Where you have a free choice, SHA-384 is the better pick if a secret is being hashed along with the message, since it is not vulnerable to length extension. For file checksums the two are equally fine, and SHA-256 is more likely to match what anybody else publishes.

Can I use SHA-384 to verify a download?

Only if the publisher published a SHA-384. Verification is a comparison, so both sides have to be the same function — computing a 96-character digest when the release notes give you 64 characters leaves you with two unrelated strings. The comparison also has to happen somewhere that can read the file: the Check a checksum tab on this page holds a pasted value against the text in the box above, not against a download, so the file side belongs in a Mac app — verifying a download on a Mac covers it. When you are the one publishing, SHA-384 is a perfectly sound choice and has the small advantage that its length identifies it on sight.

Is SHA-384 approved for government and compliance use?

Yes. It is specified in FIPS 180-4 alongside SHA-256 and SHA-512, and the NSA's Commercial National Security Algorithm suite names SHA-384 specifically for systems handling classified information. That is usually why it appears in a requirements document rather than the more familiar SHA-256 — the profile was written around a 192-bit security level, not because anybody distrusts SHA-256.