Waiting for inputSHA3-384 and SHA-384 both print 96 hex characters. A TLS suite named SHA384 almost always means the SHA-2 truncation. Hash once, then read both rows before you blame the file.
1600-bit Keccak state. SHA3-384 squeezes 384 bits from the rate side. The hidden half is why length extension fails.
Waiting for inputWaiting for inputCipher suites such as TLS_AES_256_GCM_SHA384 name SHA-384, the SHA-2 function built by cutting SHA-512 down to 384 bits. The 3 in SHA-3 is missing on purpose.
Landing on a SHA3-384 page for a TLS checksum is the mix-up I keep closing in tickets. Same 96 hex characters. Same advertised width. A verifier treats the two strings as strangers.
Paste abc in the box. Two rows fill. None of them match.
Have a 96-character checksum from a vendor PDF? Drop the file. Paste the hex into the matcher. Read the match line. Then decide whether to stay, or to open the SHA384 Hash Generator and stop re-fetching a tarball.
SHA-384 lives in FIPS 180-4. SHA3-384 lives in FIPS 202. NIST published both, years apart, with names close enough to ruin a morning.
SHA-384 runs a Merkle-Damgård chain inherited from SHA-512, then throws away the last 128 bits of the 512-bit state. The discarded bits are why SHA-384 resists length extension better than SHA-256, even though both belong to SHA-2. SHA3-384 never had the leak. The squeezed 384 bits are not the sponge's full 1600-bit state.
A spreadsheet accepts either string in the same cell. A signature verifier does not.
Opened this desk because a published checksum refused to match openssl dgst -sha3-384?
Stop hashing the file. Read the copper row. The download is often intact. The algorithm on the release page was SHA-384, or SHA3-384, and someone copied the other one into the ticket.
SHA3-256 already gives 128-bit collision resistance. Enough for almost every public checksum. SHA3-384 exists because NIST wanted a SHA-3 member sized to AES-192 and to the P-384 curve.
Collision work against a 384-bit digest costs about 2192 operations. Preimage work costs 2384. Those numbers line up with a 192-bit security level. They do not line up with "use 384 because 384 looks serious."
P-384 signatures historically pair with SHA-384, the SHA-2 truncation. Substituting SHA3-384 because the numbers match is a protocol error. The curve does not care. The verifier does.
Reach for SHA3-384 when a written profile named SHA3-384. Reach for the SHA3-256 Hash Generator for new checksums unless a reviewer asked for 192-bit collision strength. Reach for the SHA3-512 Hash Generator when the profile named 512 bits of SHA-3, not 512 bits of SHA-2.
Most new work should stay on SHA3-256. The 384-bit member is the middle child of the family. Specs name SHA3-256 or SHA3-512. SHA3-384 shows up when someone copied a SHA-384 requirement and added a 3.
Both rows below print 96 hexadecimal characters. Count them. The length will never tell you which family you hashed.
| Name | Standard | Machine | Block / rate | Where the name shows up |
|---|---|---|---|---|
| SHA3-384 | FIPS 202 | Keccak sponge, capacity 768 | 104-byte rate | Rare. Explicit SHA-3 profiles, some FIPS modules |
| SHA-384 | FIPS 180-4 | SHA-512 truncated to 384 bits | 128-byte blocks | TLS SHA384 suites, P-384 certs, sha384sum |
| SHA3-256 | FIPS 202 | Same sponge, capacity 512 | 136-byte rate | Default SHA-3 width for new checksums |
| SHA3-512 | FIPS 202 | Same sponge, capacity 1024 | 72-byte rate | When a profile asked for 512 bits of SHA-3 |
The SHA-2 Hash Generator prints SHA-224, SHA-256, SHA-384, and SHA-512 of one input together. Open there when a document said SHA-2 and refused to name a member. Stay here when the document said SHA-3 and named 384 bits.
SHA-512 beats SHA-256 on 64-bit CPUs because the wider function uses the same 64-bit arithmetic more efficiently. SHA-3 does the opposite.
Capacity is twice the digest length. Rate is whatever remains of the 1600-bit state. SHA3-384 absorbs 104 bytes per permutation. SHA3-256 absorbs 136. SHA3-512 absorbs 72. Wider SHA-3 is slower on the same message.
Nobody picks SHA3-384 for speed. The width is a security-level match, not a performance win. If a service hashes gigabytes in a browser tab, SHA3-384 is the wrong place to start. Hash on disk with OpenSSL. Or pick a shorter SHA-3 member if the profile allows SHA3-256.
SHAKE is the sponge when the output length is not 48 bytes. The SHAKE256 Hash Generator lets you name the byte count. Do not truncate a SHA3-512 digest to 48 bytes and call the result SHA3-384. The padding and the squeezed length are part of the name.
Trust this page after matching once on a machine you already own:
printf 'abc' | openssl dgst -sha3-384
python -c "import hashlib; print(hashlib.sha3_384(b'abc').hexdigest())"
openssl dgst -sha3-384 release.tar.gzThe first line must print ec01498288516fc926459f58e2c6ad8df9b473cb0fc08c2596da7cf0e49be4b298d88cea927ac7f539f1edf228376d25. The empty-string button above must print 0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004. Those are FIPS 202 Appendix A vectors. If a library disagrees with either one, the library is hashing SHA-384, or raw Keccak-384, or adding a newline you did not ask for.
echo abc appends a newline. Four bytes, not three. The digest will not match the abc chip. Use printf, or echo -n, when comparing a typed string against this page.
Windows certutil -hashfile still has no SHA-3 algorithm name in older builds. PowerShell Get-FileHash grew SHA3 names in recent versions. On a box where neither exists, OpenSSL is the boring path.
CryptoJS SHA3 in the 4.x line is the raw Keccak sponge. Output often matches neither row. Python hashlib.sha3_384 and openssl dgst -sha3-384 match the teal row. If a dependency is already emitting Keccak, keep using Keccak. Do not rename the digest SHA3-384 in a comment to make the ticket close.
SHA3-384 is built for speed relative to a password hash. A rented GPU tests guesses against the sponge at the same order of magnitude as other SHA-3 widths. Adding a salt stops a rainbow table. The salt does nothing about throughput. Password storage wants Argon2id, with bcrypt or scrypt as accepted stand-ins. A SHA-3 digest of a password is a leftover from tutorials written before those functions were common.
Keyed work still wants HMAC. Dropping HMAC because SHA-3 resists length extension is a fashionable mistake. A bare digest of a request body proves nothing about who sent the body. Use HMAC-SHA3 or HMAC-SHA-384 when a secret is involved. The HMAC Generator is the page with a key field. This desk has none on purpose.
openssl dgst -sha3-384 on the machine that holds the file. The Checksum Validator is the page for a whole manifest, not one file.Hashing never leaves the tab. There is no upload step. Close the tab and the buffers go with it. Load the page once, cut the network, and the desk keeps working, which is the point of running FIPS 202 in the browser instead of posting a release tarball to a stranger's server.
Most mismatches on this page are a family name, not a corrupt download.
Neither, if you called -sha384. That flag is SHA-2. This page prints NIST SHA3-384 on the teal row and SHA-384 on the copper row. openssl dgst -sha3-384 matches the teal row. openssl dgst -sha384 matches the copper row. The missing 3 in the flag is the whole bug.
No. TLS_AES_256_GCM_SHA384 and cousins use SHA-384 from SHA-2. Open the SHA384 Hash Generator, or run sha384sum. Stay on this desk only when the written name is SHA3-384 or SHA-3-384 with the 3 next to SHA.
The empty string is a NIST test vector. SHA3-384 of zero bytes is 0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004. A tool leaving the output blank on empty input is being polite, not correct. Click empty to confirm this page still matches Appendix A.
No. Speed is the point of SHA3-384 and the enemy of password storage. Use Argon2id. bcrypt and scrypt remain accepted alternatives. All three salt internally and cost time per guess. A salted SHA-3 digest is still a fast hash with extra steps.
For collision and preimage work against a full-width digest, both are fine for new designs at a 192-bit collision level. SHA-3 wins on length extension in the SHA-256 sense, because the squeezed bits are not the sponge state. SHA-384 already truncates SHA-512, so extension is harder there too. Pick SHA3-384 when a spec named SHA-3. Pick SHA-384 when a spec named SHA-2 or a TLS suite named SHA384.
Often CryptoJS. In the 4.x line, SHA3 is the raw Keccak sponge, even with outputLength 384. Python hashlib.sha3_384 and openssl dgst -sha3-384 match the teal row. If a dependency is already emitting Keccak, keep using Keccak. Do not rename the digest SHA3-384 in a comment to make the ticket close.
No. The ceiling is 16 MB because Keccak runs in JavaScript in the tab. openssl dgst -sha3-384 streams the file on disk and does not care about heap size. Use OpenSSL for images, installers, and anything you would not paste into a textarea.
No. SHA3-384 runs in this tab. SHA-384 uses the Web Crypto API in the same tab. Closing the page drops the buffers. A private key, an internal build, or a customer export stays on the machine.