SHA-384 Hash Generator (TLS Suite B Hash)

Was ist 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-Beispiele

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

SHA-384-Hashes generieren

1. 1

   Text einfügen oder Datei einspielen

   Wähle den Reiter "Text" und füge einen beliebigen String ein — eine Dokument-ID, einen Request-Body oder eine beliebige Eingabe — in den Eingabebereich. Der SHA-384-Hash wird während der Eingabe aktualisiert. Für Dateien wechsle zum Reiter "Datei" und ziehe eine Datei in die Drop-Zone; der Browser hasht sie lokal ohne Upload. Für große Dateien (>10 MB) erscheint ein Fortschrittsanzeiger.

2. 2

   Den 96-Zeichen-Hash kopieren

   Klicke auf die Kopieren-Schaltfläche neben der Hash-Ausgabe. Der vollständige 96-Zeichen-Kleinbuchstaben-Hex-String wird in die Zwischenablage kopiert — bereit zum Einfügen in eine TLS-Konfiguration, einen Compliance-Bericht oder eine HMAC-Implementierung. Nutze den Großbuchstaben-Schalter, wenn dein Zielsystem Großbuchstaben-Hex erfordert.

3. 3

   Mit einem bekannten Hash vergleichen

   Wechsle zum Reiter "Vergleichen" und füge zwei SHA-384-Hashes nebeneinander ein. Das Tool meldet Übereinstimmung oder Nichtübereinstimmung mit zeitkonstantem Vergleich. Nützlich zur Verifizierung von Suite B-Compliance-Hashes, zum Vergleichen von HKDF-SHA-384-abgeleiteten Schlüsseln über Implementierungen hinweg oder zur Überprüfung von Dokument-Fingerprints.

Technische Details

Algorithmus: SHA-512 mit anderem IV, Ausgabe auf 384 Bit gekürzt

SHA-384 ist strukturell identisch mit SHA-512 (FIPS 180-4, Abschnitt 6.5). Beide verwenden 80 Runden 64-Bit-Operationen (Ch, Maj, Σ0, Σ1-Funktionen) mit Konstanten aus Kubus- und Quadratwurzeln der ersten 80 Primzahlen. Der Initialisierungsvektor (acht 64-Bit-Wörter) unterscheidet sich von SHA-512s IV. Nach der Verarbeitung werden die ersten sechs 64-Bit-Wörter des Achtwort-Zustands ausgegeben (384 Bit); die letzten zwei Wörter werden verworfen.

Ausgabe: 384 Bit, 96 Hex-Zeichen

Immer genau 96 Kleinbuchstaben-Hexadezimalzeichen (384 Bit = 48 Bytes, jedes Byte als 2 Hex-Zeichen kodiert). Feste Länge unabhängig von der Eingabegröße. Die verworfenen 128 Bit — die letzten zwei 64-Bit-Zustandswörter — machen SHA-384 längenextensions-resistent.

Performance: identisch zu SHA-512 auf 64-Bit-Hardware

SHA-384 und SHA-512 führen auf 64-Bit-CPUs dieselbe Befehlssequenz aus. Beide verwenden 1024-Bit-(128-Byte-)Eingabeblöcke, verarbeitet mit 64-Bit-Rotationen und Additionen. Durchsatz: typischerweise 500–900 MB/s in einem Browser mit der Web Crypto API, und 1–3 GB/s in nativen Tools mit Hardware-SHA-Erweiterungen.

Standards: FIPS 180-4, NSA Suite B Legacy, aktuell CNSA

Standardisiert in FIPS 180-2 (2001), aktuelle Version FIPS 180-4 (2015). Von NSA Suite B (CNSSP-15, 2005) für TOP SECRET gefordert, noch in der CNSA Suite (2015) enthalten. Für TLS in RFC 5246 (TLS 1.2 PRF mit SHA-384-Cipher-Suites), RFC 8446 (TLS 1.3) und RFC 5869 (HKDF) spezifiziert. Von NIST für alle Sicherheitsstärken bis 2030 und darüber hinaus genehmigt.

Best Practices

SHA-384 verwenden, wenn Längenextensions-Immunität ohne HMAC wichtig ist

Wenn dein Protokoll die rohe Hash-Ausgabe exponiert und ein Angreifer versuchen könnte, die Nachricht zu erweitern (z. B. bestimmte Signed-URL- oder Challenge-Response-Schemata), bietet SHA-384 inherente Längenextensions-Immunität, die SHA-256 nicht hat. Für alle anderen schlüsselbasierten Verwendungen wende HMAC unabhängig vom zugrundeliegenden Hash an — HMAC-SHA-256 und HMAC-SHA-384 sind beide sicher.

Mit AES-256-GCM für Suite B/CNSA-Konformität kombinieren

Wenn du ein System baust, das NSA Suite B- oder CNSA-Anforderungen erfüllen muss, ist die kanonische Paarung AES-256-GCM für Massenverschlüsselung und SHA-384 für Integrität und Schlüsselableitung. TLS 1.2 mit ECDHE-ECDSA-AES256-GCM-SHA384 ist die Referenz-Cipher-Suite. Für TLS 1.3 entspricht das TLS_AES_256_GCM_SHA384 mit ecdsa_secp384r1_sha384 als Signaturalgorithmus.

HMAC-SHA-384 für schlüsselbasierte MAC in TLS-1.2-PRF-Kontexten verwenden

TLS 1.2s PRF verwendet HMAC-SHA-384 für Cipher-Suites, bei denen SHA-384 ausgehandelt wurde (RFC 5246, Abschnitt 5). Wenn du eine TLS-1.2-PRF implementierst oder testest: PRF(secret, label, seed) = P_SHA384(secret, label + seed). Substituiere nicht HMAC-SHA-256 in einem SHA-384-Cipher-Suite-Kontext — die Cipher-Suite-Aushandlung bestimmt den PRF-Hash, und eine Nichtübereinstimmung führt zum Handshake-Fehler.

Zeitkonstanten Vergleich beim Verifizieren von SHA-384-Hashes im Code verwenden

Wenn du zwei SHA-384-Hashes im Code vergleichst — einen Dokument-Fingerprint verifizierst, einen MAC überprüfst — verwende eine zeitkonstante Gleichheitsprüfung: Node.js crypto.timingSafeEqual(), Python hmac.compare_digest(), Go subtle.ConstantTimeCompare(). Naiver String-Vergleich gibt Timing-Informationen preis, die einem Angreifer erlauben, den erwarteten Hash Byte für Byte zu rekonstruieren.

SHA-384 FAQ