Générateur SHA-1 (160 bits, usage hérité)

Qu'est-ce que SHA-1 ?

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

await sha1('Hello, World!');
// → '0a0a9f2a6772942557ab5355d76af442f8f65e01'
// ⚠️ SHA-1 is broken — use SHA-256 for new work.

Exemples SHA-1

tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author A Dev <dev@example.com> 1716854400 +0000
committer A Dev <dev@example.com> 1716854400 +0000

Initial commit

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKlL...
-----END CERTIFICATE-----

node-v0.12.7-linux-x64.tar.gz

(Collez le contenu du fichier shattered-1.pdf de Google/CWI via l'onglet Fichier)

Comment générer des hashes SHA-1

1. 1

   Collez du texte ou déposez un fichier

   Sélectionnez l'onglet Texte et collez n'importe quelle chaîne — un message de commit, un corps de certificat ou une entrée de checksum hérité — dans la zone de saisie. Le hash SHA-1 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 sans envoi.

2. 2

   Copiez le hash de 40 caractères

   Cliquez sur le bouton Copier à côté de la sortie du hash. La chaîne hexadécimale complète en minuscules de 40 caractères va dans votre presse-papiers. Utilisez le bouton Majuscules si votre système hérité attend de l'hexadécimal en majuscules — certains outils anciens et APIs Windows utilisent les majuscules par défaut.

3. 3

   Comparez avec une empreinte héritée

   Passez à l'onglet Comparer et collez deux hashes SHA-1 côte à côte pour confirmer qu'ils correspondent. Utile pour valider la somme de contrôle d'un éditeur hérité, auditer un dépôt Git miroir ou vérifier une ancienne empreinte de certificat TLS issue d'un document antérieur à l'adoption de SHA-256.

Détails techniques

Algorithme : construction Merkle-Damgård, 80 tours

SHA-1 traite l'entrée en blocs de 512 bits (64 octets), appliquant 80 tours d'opérations binaires regroupés en quatre étapes de 20 tours, chacune avec une fonction logique différente (Ch, Parité, Maj, Parité) et une constante additive dérivée des racines carrées de petits entiers. L'état de hachage initial est cinq mots de 32 bits (A–E), et le hash final est la concaténation de ces mots après le dernier bloc. Implémentation définie dans FIPS 180-1 (1995), remplacée par FIPS 180-4 (2015) qui inclut formellement la dépréciation.

Sortie : 160 bits, 40 caractères hexadécimaux

Toujours exactement 40 caractères hexadécimaux en minuscules (160 bits = 20 octets, encodés en 2 hex par octet). La longueur de sortie est fixe quelle que soit la taille de l'entrée. Comparé aux 64 caractères de SHA-256, la sortie plus courte offre moins de bits de résistance aux collisions — un facteur clé de pourquoi SHA-1 a été rompu avant SHA-256.

Performance : rapide, mais c'est en partie le problème

SHA-1 est rapide — typiquement 400–700 Mo/s dans un navigateur via Web Crypto, compétitif avec SHA-256. Pour un attaquant, cette vitesse est un avantage : un cluster GPU moderne peut calculer des milliards de hashes SHA-1 par seconde, accélérant la recherche par force brute et les recherches de collisions. La vitesse est la raison pour laquelle SHA-1 (comme MD5) ne doit jamais être utilisé pour le stockage de mots de passe — utilisez bcrypt, scrypt ou Argon2 à la place.

Normes : FIPS 180-1 (1995) — déprécié dans le contexte FIPS 180-4

SHA-1 a été standardisé dans FIPS 180-1 (1995), remplaçant le SHA-0 défectueux. Le NIST a déprécié SHA-1 pour les signatures numériques dans NIST SP 800-131A (2011) et dans FIPS 186-5 (2023) l'a formellement interdit pour toute génération de signature numérique. RFC 6194 (2011) a documenté les considérations de sécurité connues. L'API WebCrypto du W3C inclut encore SHA-1 pour des raisons d'interopérabilité legacy, ce qui est la raison pour laquelle cet outil navigateur peut le calculer.

Bonnes pratiques

N'utilisez jamais SHA-1 pour des opérations sensibles à la sécurité

SHA-1 est déprécié pour les signatures numériques, les certificats TLS, la signature de code, le stockage de mots de passe et tout flux où la résistance aux collisions est importante. L'attaque SHAttered de 2017 a démontré des collisions pratiques. Pour tous les usages sécuritaires, migrez vers SHA-256 ou SHA-3. La différence de coût est négligeable sur le matériel moderne — SHA-256 est accéléré matériellement dans tous les CPU et GPU actuels.

SHA-1 pour la recherche d'empreintes héritées est acceptable

Si vous devez vérifier une somme de contrôle de fichier antérieure à 2017, rechercher un ID de commit Git ou inspecter une ancienne empreinte de certificat à des fins d'audit, SHA-1 est approprié. Le hash lui-même n'est pas utilisé pour prendre une décision de confiance — vous reproduisez simplement une empreinte connue pour référence croisée. Documentez ceci explicitement dans vos journaux d'audit : « SHA-1 utilisé pour référence héritée uniquement, pas pour validation sécuritaire. »

Hachez toujours des octets UTF-8, pas des points de code Unicode

SHA-1, comme tous les algorithmes de hachage, opère sur des octets, pas sur des caractères. La même chaîne encodée en UTF-8 vs UTF-16 produit des hashes différents. Cet outil encode toujours l'entrée en UTF-8 sans BOM avant le hachage. Si vous devez correspondre à un système utilisant un encodage différent (Windows UTF-16-LE, Latin-1), vous devez pré-encoder l'entrée en externe avant de comparer les hashes.

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

Si vous comparez deux hashes SHA-1 dans du code, utilisez une vérification d'égalité en temps constant — Node.js crypto.timingSafeEqual(), Python hmac.compare_digest() — plutôt que l'égalité de chaînes naïve (=== ou ==). La comparaison naïve divulgue des informations de timing qui peuvent théoriquement permettre à un attaquant de reconstruire le hash attendu octet par octet. C'est une mesure de défense en profondeur même pour la vérification SHA-1 legacy.

Questions fréquentes SHA-1