SHA-384 Hash Generator (TLS Suite B hash)

Wat 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 voorbeelden

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"}

Zo genereer je SHA-384 hashes

1. 1

   Tekst plakken of bestand slepen

   Selecteer het tabblad Tekst en plak een willekeurige string — een document-ID, aanvraagtekst of willekeurige invoer — in het invoerveld. De SHA-384 hash wordt bijgewerkt terwijl je typt. Voor bestanden ga je naar het tabblad Bestand en sleep je een bestand naar de dropzone; de browser verwerkt het lokaal via de Web Crypto API zonder upload. Een voortgangsindicator verschijnt bij grote bestanden (>10 MB).

2. 2

   De 96-tekens hash kopiëren

   Klik op de knop Kopiëren naast de hash output. De volledige 96-tekens hex string in kleine letters gaat naar je klembord — klaar om te plakken in een TLS-configuratie, nalevingsrapport of HMAC-implementatie. Gebruik de schakelaar Hoofdletters als je doelsysteem hoofdletters hex vereist.

3. 3

   Vergelijken met een bekende hash

   Ga naar het tabblad Vergelijken en plak twee SHA-384 hashes naast elkaar. De tool meldt overeenkomst of geen overeenkomst via constante-tijd vergelijking, die geen timing-informatie lekt. Handig voor het verifiëren van Suite B-nalevings-hashes, het vergelijken van HKDF-SHA-384 afgeleide sleutels in verschillende implementaties, of het controleren van documentvingerafdrukken in geclassificeerde archiefaudits.

Technische details

Algoritme: SHA-512 met andere IV, output afgekapt tot 384 bits

SHA-384 is structureel identiek aan SHA-512 (FIPS 180-4 sectie 6.5). Beide gebruiken 80 rondes van 64-bit bewerkingen (Ch, Maj, Σ0, Σ1 functies) met constanten afgeleid van de kubieke en vierkantswortels van de eerste 80 priemgetallen. De initialisatievector (acht 64-bit woorden) verschilt van SHA-512's IV — SHA-384's IV is afgeleid van de fractionele delen van de vierkantswortels van het 9e t/m 16e priemgetal. Na verwerking worden de eerste zes 64-bit woorden van de acht-woord toestand als output gegeven (384 bits); de laatste twee woorden worden weggegooid.

Output: 384 bits, 96 hexadecimale tekens

Altijd precies 96 kleine hexadecimale tekens (384 bits = 48 bytes, elke byte gecodeerd als 2 hex-tekens). Vast van lengte, ongeacht de invoergrootte. De 96-tekens lengte is de onmiddellijke vingerafdruk die SHA-384 onderscheidt van SHA-256 (64 tekens) en SHA-512 (128 tekens). De weggegooid 128 bits — de laatste twee 64-bit toestandswoorden — maken SHA-384 bestand tegen length-extension aanvallen.

Prestaties: identiek aan SHA-512 op 64-bit hardware

SHA-384 en SHA-512 voeren dezelfde instructiereeks uit op 64-bit CPU's. Beide gebruiken 1024-bit (128-byte) invoerblokken, verwerkt met 64-bit rotaties en optellingen. Doorvoer is doorgaans 500–900 MB/s in een browser via de Web Crypto API (die native C/Rust-code buiten de JS VM aanroept), en 1–3 GB/s in native tools met hardware SHA-extensies. Op 32-bit hardware of zonder hardwareversnelling zijn SHA-384/512 langzamer dan SHA-256 vanwege emulatie van 64-bit gehele-getalsrekenklunde.

Standaarden: FIPS 180-4, NSA Suite B (verouderd), CNSA (huidig)

Gestandaardiseerd in FIPS 180-2 (2001), huidige versie FIPS 180-4 (2015). Vereist door NSA Suite B (CNSSP-15, 2005) voor TOP SECRET, nog steeds aanwezig in de CNSA Suite (2015). Gespecificeerd voor TLS in RFC 5246 (TLS 1.2 PRF met SHA-384 ciphersuites), RFC 8446 (TLS 1.3 handtekeningalgoritme ecdsa_secp384r1_sha384) en RFC 5869 (HKDF). Door NIST goedgekeurd voor alle beveiligingsniveaus tot 2030 en daarna onder NIST SP 800-131A Rev 2.

Aanbevolen aanpak

Gebruik SHA-384 wanneer length-extension immuniteit van belang is zonder HMAC

Als je protocol de ruwe hash-output blootstelt en een aanvaller zou kunnen proberen het bericht uit te breiden (bijv. bepaalde ondertekende URL- of challenge-response-schema's), biedt SHA-384 ingebouwde length-extension immuniteit die SHA-256 niet heeft. Pas voor al het andere gebruik met sleutel HMAC toe, ongeacht de onderliggende hash — HMAC-SHA-256 en HMAC-SHA-384 zijn beide veilig, en HMAC elimineert length-extension aanvallen voor elke SHA-2 variant.

Combineer met AES-256-GCM voor Suite B / CNSA-compliance

Als je een systeem bouwt dat moet voldoen aan NSA Suite B of CNSA-vereisten, is de canonieke combinatie AES-256-GCM voor bulkversleuteling en SHA-384 voor integriteit en sleutelafleiding. TLS 1.2 met ECDHE-ECDSA-AES256-GCM-SHA384 is de referentie-ciphersuite. Voor TLS 1.3 is het equivalent TLS_AES_256_GCM_SHA384 met ecdsa_secp384r1_sha384 als handtekeningalgoritme. Bevestig dat je TLS-bibliotheek deze ciphersuites daadwerkelijk onderhandelt — sommige standaardwaarden geven de voorkeur aan AES-128 varianten, zelfs op Suite B-geconfigureerde systemen.

Gebruik HMAC-SHA-384 voor keyed MAC in TLS 1.2 PRF-contexten

De PRF van TLS 1.2 gebruikt HMAC-SHA-384 voor ciphersuites waarbij SHA-384 is onderhandeld (RFC 5246 sectie 5). Als je een TLS 1.2 PRF implementeert of test: PRF(geheim, label, seed) = P_SHA384(geheim, label + seed). Vervang HMAC-SHA-256 niet in een SHA-384 ciphersuite context — de ciphersuite-onderhandeling bepaalt de PRF-hash, en het niet overeenkomen ervan veroorzaakt een handshake-fout. Verifieer met testvectoren van RFC 5705 (keying material exporters) of RFC 6070 (PBKDF2).

Gebruik constante-tijd vergelijking bij het verifiëren van SHA-384 hashes in code

Als je twee SHA-384 hashes in code vergelijkt — een documentvingerafdruk verifieert, een MAC controleert — gebruik dan een constante-tijd gelijkheidscontrole: Node.js crypto.timingSafeEqual(), Python hmac.compare_digest(), Go subtle.ConstantTimeCompare(). Naïeve stringvergelijking (=== of ==) lekt timing-informatie waarmee een aanvaller de verwachte hash byte voor byte kan reconstrueren in ~768 vergelijkingen (96 tekens × 8 bits). Dit is een kritieke defense-in-depth maatregel voor elk authenticatiesysteem.

Veelgestelde vragen over SHA-384