Générateur SHA-384 (Hash Suite B TLS)

Qu'est-ce que 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'

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

Comment générer des hashes SHA-384

1. 1

   Collez du texte ou déposez un fichier

   Sélectionnez l'onglet Texte et collez n'importe quelle chaîne — un ID de document, un corps de requête ou une entrée arbitraire — dans la zone de saisie. Le hash SHA-384 se met à jour au fil de la frappe. Pour les fichiers, passez à l'onglet Fichier et faites glisser n'importe quel fichier dans la zone de dépôt ; le navigateur le hache localement via la Web Crypto API sans envoi. Un indicateur de progression apparaît pour les fichiers volumineux (>10 Mo).

2. 2

   Copiez le hash de 96 caractères

   Cliquez sur le bouton Copier à côté de la sortie du hash. La chaîne hexadécimale complète en minuscules de 96 caractères va dans votre presse-papiers — prête à coller dans une configuration TLS, un rapport de conformité ou une implémentation HMAC. Utilisez le bouton Majuscules si votre système cible requiert de l'hexadécimal en majuscules.

3. 3

   Comparez avec un hash connu

   Passez à l'onglet Comparer et collez deux hashes SHA-384 côte à côte. L'outil signale la correspondance ou la non-correspondance en utilisant une comparaison en temps constant, sans divulguer d'informations de timing. Utile pour vérifier des hashes de conformité Suite B, comparer des clés dérivées HKDF-SHA-384 entre implémentations, ou vérifier des empreintes de documents dans des audits d'archives classifiées.

Détails techniques

Algorithme : SHA-512 avec IV différent, sortie tronquée à 384 bits

SHA-384 est structurellement identique à SHA-512 (FIPS 180-4 section 6.5). Les deux utilisent 80 tours d'opérations 64 bits (fonctions Ch, Maj, Σ0, Σ1) avec des constantes dérivées des racines cubiques et carrées des 80 premiers nombres premiers. Le vecteur d'initialisation (huit mots de 64 bits) diffère de celui de SHA-512 — l'IV de SHA-384 est dérivé des parties fractionnaires des racines carrées des 9e au 16e nombres premiers. Après le traitement, les six premiers mots de 64 bits des huit mots d'état sont produits (384 bits) ; les deux derniers mots sont éliminés.

Sortie : 384 bits, 96 caractères hexadécimaux

Toujours exactement 96 caractères hexadécimaux en minuscules (384 bits = 48 octets, chaque octet encodé en 2 hex). Longueur fixe quelle que soit la taille de l'entrée. La longueur de 96 caractères distingue immédiatement SHA-384 de SHA-256 (64 caractères) et SHA-512 (128 caractères). Les 128 bits éliminés — les deux derniers mots d'état de 64 bits — sont ce qui rend SHA-384 résistant à l'extension de longueur.

Performance : identique à SHA-512 sur le matériel 64 bits

SHA-384 et SHA-512 exécutent la même séquence d'instructions sur les CPU 64 bits. Les deux utilisent des blocs d'entrée de 1024 bits (128 octets), traités avec des rotations et additions 64 bits. Le débit est typiquement de 500–900 Mo/s dans un navigateur via la Web Crypto API (qui appelle du code C/Rust natif hors de la VM JS), et de 1–3 Go/s dans les outils natifs avec les extensions SHA matérielles. Sur le matériel 32 bits ou sans accélération matérielle, SHA-384/512 sont plus lents que SHA-256 en raison de l'émulation des entiers 64 bits.

Normes : FIPS 180-4, NSA Suite B (legacy), CNSA (actuel)

Standardisé dans FIPS 180-2 (2001), version actuelle FIPS 180-4 (2015). Requis par la NSA Suite B (CNSSP-15, 2005) pour TOP SECRET, toujours présent dans la suite CNSA (2015). Spécifié pour TLS dans RFC 5246 (PRF TLS 1.2 avec suites SHA-384), RFC 8446 (algorithme de signature TLS 1.3 ecdsa_secp384r1_sha384) et RFC 5869 (HKDF). Approuvé par le NIST pour tous les niveaux de sécurité jusqu'en 2030 et au-delà selon NIST SP 800-131A Rev 2.

Bonnes pratiques

Utilisez SHA-384 quand l'immunité contre l'extension de longueur est importante sans HMAC

Si votre protocole expose la sortie de hash brut et qu'un attaquant pourrait tenter d'étendre le message (par exemple dans certains schémas d'URL signées ou de challenge-réponse), SHA-384 offre une immunité inhérente contre l'extension de longueur que SHA-256 ne possède pas. Pour tous les autres usages avec clé, appliquez HMAC quel que soit le hash sous-jacent — HMAC-SHA-256 et HMAC-SHA-384 sont tous deux sûrs, et HMAC élimine les attaques par extension de longueur pour toute variante SHA-2.

Associez à AES-256-GCM pour la conformité Suite B / CNSA

Si vous construisez un système devant se conformer aux exigences NSA Suite B ou CNSA, l'association canonique est AES-256-GCM pour le chiffrement de masse et SHA-384 pour l'intégrité et la dérivation de clés. TLS 1.2 avec ECDHE-ECDSA-AES256-GCM-SHA384 est la suite de référence. Pour TLS 1.3, l'équivalent est TLS_AES_256_GCM_SHA384 avec ecdsa_secp384r1_sha384 comme algorithme de signature. Confirmez que votre bibliothèque TLS négocie effectivement ces suites — certaines valeurs par défaut préfèrent les variantes AES-128 même sur les systèmes configurés Suite B.

Utilisez HMAC-SHA-384 pour les MAC à clé dans les contextes PRF TLS 1.2

La PRF TLS 1.2 utilise HMAC-SHA-384 pour les suites où SHA-384 a été négocié (RFC 5246 section 5). Si vous implémentez ou testez une PRF TLS 1.2 : PRF(secret, label, seed) = P_SHA384(secret, label + seed). Ne substituez pas HMAC-SHA-256 dans un contexte de suite SHA-384 — la négociation de suite détermine le hash PRF, et une inadéquation provoque l'échec de la poignée de main.

Utilisez une comparaison en temps constant lors de la vérification de hashes SHA-384 dans le code

Si vous comparez deux hashes SHA-384 dans du code — vérification d'une empreinte de document, contrôle d'un MAC — utilisez une vérification d'égalité en temps constant : Node.js crypto.timingSafeEqual(), Python hmac.compare_digest(), Go subtle.ConstantTimeCompare(). L'égalité de chaînes naïve (=== ou ==) divulgue des informations de timing permettant à un attaquant de reconstruire le hash attendu octet par octet en ~768 comparaisons (96 caractères × 8 bits). C'est une mesure de défense en profondeur critique pour tout système d'authentification.

Questions fréquentes SHA-384