Generator SHA-384 hash (TLS Suite B)

Czym jest 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'

Przykłady SHA-384

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

Jak generować hashe SHA-384

1. 1

   Wklej tekst lub upuść plik

   Wybierz zakładkę Tekst i wklej dowolny ciąg — identyfikator dokumentu, treść żądania lub dowolne dane wejściowe — do obszaru wejściowego. Hash SHA-384 aktualizuje się na bieżąco podczas pisania. W przypadku plików przełącz na zakładkę Plik i przeciągnij dowolny plik do strefy upuszczania; przeglądarka hashuje go lokalnie za pomocą Web Crypto API bez przesyłania. Dla dużych plików (>10 MB) pojawia się wskaźnik postępu.

2. 2

   Skopiuj 96-znakowy hash

   Kliknij przycisk Kopiuj obok wyjścia hash. Pełny 96-znakowy ciąg hex małymi literami trafia do schowka — gotowy do wklejenia do konfiguracji TLS, raportu zgodności lub implementacji HMAC. Użyj przełącznika Wielkie litery, jeśli system docelowy wymaga wielkich liter hex.

3. 3

   Porównaj ze znanych hashem

   Przełącz na zakładkę Porównaj i wklej dwa hashe SHA-384 obok siebie. Narzędzie zgłasza zgodność lub niezgodność za pomocą porównania w stałym czasie, które nie ujawnia informacji o czasie. Przydatne do weryfikacji hashy zgodności Suite B, porównywania kluczy wyprowadzonych HKDF-SHA-384 między implementacjami lub sprawdzania odcisków dokumentów w audytach archiwów tajnych.

Szczegóły techniczne

Algorytm: SHA-512 z innym IV, wyjście skrócone do 384 bitów

SHA-384 jest strukturalnie identyczny z SHA-512 (FIPS 180-4 sekcja 6.5). Oba używają 80 rund 64-bitowych operacji (funkcje Ch, Maj, Σ0, Σ1) ze stałymi pochodnymi od pierwiastków sześciennych i kwadratowych pierwszych 80 liczb pierwszych. Wektor inicjalizacji (osiem 64-bitowych słów) różni się od IV SHA-512 — IV SHA-384 jest pochodną ułamkowych części pierwiastków kwadratowych 9. do 16. liczby pierwszej. Po przetworzeniu wyprowadzanych jest pierwsze sześć 64-bitowych słów z ośmiosłowowego stanu (384 bity); dwa ostatnie słowa są odrzucane.

Wyjście: 384 bity, 96 znaków hex

Zawsze dokładnie 96 małych liter szesnastkowych (384 bity = 48 bajtów, każdy bajt zakodowany jako 2 znaki hex). Stała długość niezależnie od rozmiaru wejścia. 96-znakowa długość to natychmiastowy odcisk odróżniający SHA-384 od SHA-256 (64 znaki) i SHA-512 (128 znaków). Odrzucone 128 bitów — dwa ostatnie 64-bitowe słowa stanu — sprawiają, że SHA-384 jest odporny na rozszerzenie długości.

Wydajność: identyczna z SHA-512 na sprzęcie 64-bitowym

SHA-384 i SHA-512 wykonują tę samą sekwencję instrukcji na procesorach 64-bitowych. Oba używają 1024-bitowych (128-bajtowych) bloków wejściowych, przetwarzanych z 64-bitowymi rotacjami i dodawaniami. Przepustowość wynosi zazwyczaj 500–900 MB/s w przeglądarce za pomocą Web Crypto API (który wywołuje natywny kod C/Rust poza maszyną wirtualną JS) i 1–3 GB/s w natywnych narzędziach ze sprzętowymi rozszerzeniami SHA.

Standardy: FIPS 180-4, legacy NSA Suite B, aktualny CNSA

Wystandaryzowany w FIPS 180-2 (2001), aktualna wersja FIPS 180-4 (2015). Wymagany przez NSA Suite B (CNSSP-15, 2005) dla ściśle tajnego, nadal obecny w CNSA Suite (2015). Określony dla TLS w RFC 5246 (PRF TLS 1.2 z zestawami szyfrów SHA-384), RFC 8446 (algorytm podpisu TLS 1.3 ecdsa_secp384r1_sha384) i RFC 5869 (HKDF). Zatwierdzone przez NIST dla wszystkich poziomów siły bezpieczeństwa do 2030 roku i dalej zgodnie z NIST SP 800-131A Rev 2.

Najlepsze praktyki

Używaj SHA-384, gdy liczy się odporność na rozszerzenie długości bez HMAC

Jeśli protokół ujawnia surowe wyjście hash i atakujący mógłby próbować rozszerzyć wiadomość (np. w pewnych schematach podpisanych URL lub challenge-response), SHA-384 zapewnia wbudowaną odporność na rozszerzenie długości, której SHA-256 nie posiada. We wszystkich innych zastosowaniach opartych na kluczu stosuj HMAC niezależnie od bazowego hash — HMAC-SHA-256 i HMAC-SHA-384 są oba bezpieczne, a HMAC eliminuje ataki rozszerzenia długości dla dowolnego wariantu SHA-2.

Paruj z AES-256-GCM dla zgodności z Suite B / CNSA

Jeśli budujesz system, który musi być zgodny z wymaganiami NSA Suite B lub CNSA, kanonicznym parowaniem jest AES-256-GCM dla szyfrowania masowego i SHA-384 dla integralności i wyprowadzania kluczy. TLS 1.2 z ECDHE-ECDSA-AES256-GCM-SHA384 to referencyjny zestaw szyfrów. Dla TLS 1.3 odpowiednikiem jest TLS_AES_256_GCM_SHA384 z ecdsa_secp384r1_sha384 jako algorytmem podpisu. Potwierdź, że biblioteka TLS faktycznie negocjuje te zestawy szyfrów.

Używaj HMAC-SHA-384 dla MAC opartego na kluczu w kontekstach PRF TLS 1.2

PRF TLS 1.2 używa HMAC-SHA-384 dla zestawów szyfrów, gdzie SHA-384 był wynegocjowany (RFC 5246 sekcja 5). Jeśli implementujesz lub testujesz PRF TLS 1.2: PRF(secret, label, seed) = P_SHA384(secret, label + seed). Nie zastępuj HMAC-SHA-256 w kontekście zestawu szyfrów SHA-384 — negocjacja zestawu szyfrów określa hash PRF, a niezgodność powoduje niepowodzenie uzgadniania. Weryfikuj za pomocą wektorów testowych z RFC 5705 lub RFC 6070.

Używaj porównania w stałym czasie przy weryfikacji hashy SHA-384 w kodzie

Jeśli porównujesz dwa hashe SHA-384 w kodzie — weryfikując odcisk dokumentu, sprawdzając MAC — użyj sprawdzania równości w stałym czasie: crypto.timingSafeEqual() w Node.js, hmac.compare_digest() w Pythonie, subtle.ConstantTimeCompare() w Go. Naiwna równość ciągów (=== lub ==) ujawnia informacje o czasie, które mogą pozwolić atakującemu na odtworzenie oczekiwanego hasha bajt po bajcie w ~768 porównaniach (96 znaków × 8 bitów).

Najczęściej zadawane pytania