SHA-384 Hash Generator (TLS Suite B Hash)

What Is SHA-384?

// Hash text using Web Crypto API (SHA-384)
async function sha384(text) {
  const data = new TextEncoder().encode(text);
  const hash = await crypto.subtle.digest('SHA-384', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

await sha384('Hello, World!');
// → '5485cc9b3365b4305dfb4e8337e0a598a574f8242bf17289e0dd6c20a3cd44a089de16ab4ab308f63e44b1170eb5f515'

SHA-384 Examples

ECDHE-ECDSA-AES256-GCM-SHA384

master secret || client random || server random

CLASSIFIED//TS//SI//NF — Document ID: TSC-2026-0001

POST /api/v2/transfer
Content-Type: application/json
{"amount":10000,"to":"account-XYZ"}

How to Generate SHA-384 Hashes

1. 1

   Paste text or drop a file

   Select the Text tab and paste any string — a document ID, request body, or arbitrary input — into the input area. The SHA-384 hash updates as you type. For files, switch to the File tab and drag any file into the dropzone; the browser hashes it locally using the Web Crypto API with no upload. A progress indicator appears for large files (>10 MB).

2. 2

   Copy the 96-character hash

   Click the Copy button next to the hash output. The full 96-character lowercase hex string goes to your clipboard — ready to paste into a TLS configuration, compliance report, or HMAC implementation. Use the Uppercase toggle if your target system requires uppercase hex.

3. 3

   Compare against a known hash

   Switch to the Compare tab and paste two SHA-384 hashes side by side. The tool reports match or mismatch using constant-time comparison, which does not leak timing information. Useful for verifying Suite B compliance hashes, comparing HKDF-SHA-384 derived keys across implementations, or checking document fingerprints in classified archive audits.

Technical Details

Algorithm: SHA-512 with different IV, output truncated to 384 bits

SHA-384 is structurally identical to SHA-512 (FIPS 180-4 section 6.5). Both use 80 rounds of 64-bit operations (Ch, Maj, Σ0, Σ1 functions) with constants derived from the cube and square roots of the first 80 primes. The initialization vector (eight 64-bit words) differs from SHA-512's IV — SHA-384's IV is derived from the fractional parts of the square roots of the 9th through 16th primes. After processing, the first six 64-bit words of the eight-word state are output (384 bits); the final two words are discarded.

Output: 384 bits, 96 hex characters

Always exactly 96 lowercase hexadecimal characters (384 bits = 48 bytes, each byte encoded as 2 hex chars). Fixed-length regardless of input size. The 96-character length is the immediate fingerprint that distinguishes SHA-384 from SHA-256 (64 chars) and SHA-512 (128 chars). The discarded 128 bits — the last two 64-bit state words — are what make SHA-384 length-extension resistant.

Performance: identical to SHA-512 on 64-bit hardware

SHA-384 and SHA-512 execute the same instruction sequence on 64-bit CPUs. Both use 1024-bit (128-byte) input blocks, processed with 64-bit rotations and additions. Throughput is typically 500–900 MB/s in a browser using the Web Crypto API (which calls native C/Rust code outside the JS VM), and 1–3 GB/s in native tools with hardware SHA extensions. On 32-bit hardware or without hardware acceleration, SHA-384/512 are slower than SHA-256 due to 64-bit integer emulation.

Standards: FIPS 180-4, NSA Suite B legacy, CNSA current

Standardized in FIPS 180-2 (2001), current version FIPS 180-4 (2015). Required by NSA Suite B (CNSSP-15, 2005) for TOP SECRET, still present in the CNSA Suite (2015). Specified for TLS in RFC 5246 (TLS 1.2 PRF with SHA-384 ciphersuites), RFC 8446 (TLS 1.3 signature algorithm ecdsa_secp384r1_sha384), and RFC 5869 (HKDF). NIST-approved for all security strength levels through 2030 and beyond under NIST SP 800-131A Rev 2.

Best Practices

Use SHA-384 when length-extension immunity matters without HMAC

If your protocol exposes the raw hash output and an attacker could attempt to extend the message (e.g., certain signed-URL or challenge-response schemes), SHA-384 provides inherent length-extension immunity that SHA-256 does not. For all other keyed uses, apply HMAC regardless of the underlying hash — HMAC-SHA-256 and HMAC-SHA-384 are both safe, and HMAC eliminates length-extension attacks for any SHA-2 variant.

Pair with AES-256-GCM for Suite B / CNSA compliance

If you are building a system that must comply with NSA Suite B or CNSA requirements, the canonical pairing is AES-256-GCM for bulk encryption and SHA-384 for integrity and key derivation. TLS 1.2 with ECDHE-ECDSA-AES256-GCM-SHA384 is the reference ciphersuite. For TLS 1.3, the equivalent is TLS_AES_256_GCM_SHA384 with ecdsa_secp384r1_sha384 as the signature algorithm. Confirm your TLS library actually negotiates these ciphersuites — some defaults prefer AES-128 variants even on Suite B configured systems.

Use HMAC-SHA-384 for keyed MAC in TLS 1.2 PRF contexts

TLS 1.2's PRF uses HMAC-SHA-384 for ciphersuites where SHA-384 was negotiated (RFC 5246 section 5). If you are implementing or testing a TLS 1.2 PRF: PRF(secret, label, seed) = P_SHA384(secret, label + seed). Do not substitute HMAC-SHA-256 in a SHA-384 ciphersuite context — the ciphersuite negotiation determines the PRF hash, and mismatching them causes handshake failure. Verify with test vectors from RFC 5705 (keying material exporters) or RFC 6070 (PBKDF2).

Use constant-time comparison when verifying SHA-384 hashes in code

If you are comparing two SHA-384 hashes in code — verifying a document fingerprint, checking a MAC — use a constant-time equality check: Node.js crypto.timingSafeEqual(), Python hmac.compare_digest(), Go subtle.ConstantTimeCompare(). Naive string equality (=== or ==) leaks timing information that can allow an attacker to reconstruct the expected hash byte-by-byte in ~768 comparisons (96 chars × 8 bits). This is a critical defense-in-depth measure for any authentication system.

SHA-384 FAQ