Générateur Hash SHA-1 et Vérificateur de Checksum

Générez un hash SHA-1 depuis un texte ou un fichier et vérifiez-le face à un checksum SHA1SUM publié. Verdict correspond/ne correspond pas, via Web Crypto.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Générateur Hash SHA-1 - Générer Checksums SHA-1 en Ligne

Générateur hash SHA-1 gratuit en ligne créant checksums SHA-1 160-bit depuis toute entrée texte. Parfait pour développeurs et administrateurs système nécessitant hashes SHA-1 pour systèmes hérités, commits Git et tests développement. Traitement rapide côté client avec résultats instantanés.

Qu'est-ce que SHA-1 et comment fonctionne-t-il ?

SHA-1 (Secure Hash Algorithm 1) est une fonction de hachage cryptographique conçue par la NSA et publiée par le NIST en 1995 sous FIPS PUB 180-1. Elle produit un hash de 160 bits (20 octets), typiquement représenté sous forme de chaîne hexadécimale de 40 caractères. SHA-1 traite l'entrée en blocs de 512 bits à travers 80 rondes d'opérations bit à bit, d'additions modulaires et de rotations. L'entrée est complétée jusqu'à un multiple de 512 bits avec la longueur codée sur les 64 derniers bits. La sortie est déterministe — la même entrée produit toujours le même hash. SHA-1 a été largement utilisé dans TLS, Git et les signatures numériques avant d'être déconseillé pour les usages de sécurité.

SHA-1 est-il encore sûr à utiliser ?

Non — SHA-1 est cryptographiquement cassé en ce qui concerne la résistance aux collisions. En février 2017 Google et CWI Amsterdam ont publié « SHAttered », la première attaque pratique en collision produisant deux fichiers PDF distincts avec des hashes SHA-1 identiques (article : shattered.io). Le coût de l'attaque s'élevait à environ 110 000 $ en cloud. Le NIST a officiellement déconseillé SHA-1 en 2011 (SP 800-131A) et l'a interdit pour les signatures numériques en 2014. Les navigateurs modernes (Chrome 56+, Firefox 51+, Safari 11+) rejettent les certificats TLS signés en SHA-1. Utilisez SHA-256, SHA-3 ou BLAKE3 pour toute nouvelle application cryptographique. SHA-1 reste acceptable uniquement pour des usages non sécuritaires comme les checksums de contenu ou les identifiants de commit Git.

Pourquoi Git utilise-t-il toujours SHA-1 ?

Git utilise SHA-1 pour générer l'ID de commit, le hash de tree et le hash de blob. Linus Torvalds a choisi SHA-1 en 2005 pour sa rapidité et son unicité suffisante en environnement non adversarial. Git migre vers SHA-256 — Git 2.29 (octobre 2020) a ajouté le support expérimental des dépôts SHA-256. Les attaques par collision de type SHAttered ne sont pas pratiques dans Git car créer un contenu malveillant correspondant au SHA-1 d'un commit existant est bien plus difficile que produire deux fichiers arbitraires entrant en collision. Le projet Git a documenté des mesures de durcissement en 2018 pour détecter les attaques type SHAttered au niveau protocole. Les nouveaux dépôts devraient opter pour `git init --object-format=sha256` pour se préparer à l'avenir, bien que la compatibilité SHA-1 soit toujours le défaut actuel.

En quoi SHA-1 diffère-t-il de MD5 et SHA-256 ?

MD5 produit 128 bits (32 caractères hex), SHA-1 produit 160 bits (40 caractères hex), SHA-256 produit 256 bits (64 caractères hex). MD5 a été cassé en 2004 (attaque par collision Wang et al.) ; SHA-1 a été cassé en 2017 (SHAttered). SHA-256 (partie de la famille SHA-2, FIPS PUB 180-4) reste sûr en 2025 sans attaque pratique connue. SHA-256 est environ 50 pour cent plus lent que SHA-1 sur les CPU modernes mais bénéficie d'une accélération matérielle via Intel SHA extensions et ARMv8 Crypto extensions. Pour les nouvelles applications utilisez SHA-256 ou SHA-3 ; n'utilisez jamais MD5 ni SHA-1 à des fins cryptographiques.

Peut-on inverser SHA-1 pour retrouver l'entrée originale ?

Non — SHA-1 est une fonction à sens unique par conception. Étant donné un hash, aucune opération mathématique ne permet de retrouver l'entrée originale. Cependant, pour des entrées courtes ou de faible entropie (mots de passe, mots courants), les attaquants peuvent utiliser des rainbow tables (correspondances précalculées hash → entrée) ou des attaques par force brute/dictionnaire. Pour un mot de passe alphanumérique minuscule de 8 caractères, les GPU modernes peuvent calculer les 2,8 mille milliards de hashes SHA-1 possibles en moins d'un jour. C'est pourquoi SHA-1 (et SHA-256) ne doivent jamais être utilisés pour stocker des mots de passe directement — utilisez bcrypt, Argon2id, scrypt ou PBKDF2 avec un salage approprié et de nombreuses itérations. NIST SP 800-63B exige Argon2 ou bcrypt pour le stockage des mots de passe.

Générateur Hash SHA-1 et Vérificateur de Checksum — Générez un hash SHA-1 depuis un texte ou un fichier et vérifiez-le face à un checksum SHA1SUM publié. Verdict correspond — **Générateur Hash SHA-1 et Vérificateur de Checksum**

Comment générer un hash SHA-1 en code ?

Python : `import hashlib; hashlib.sha1(b'hello').hexdigest()` retourne 'aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d'. JavaScript (navigateur) : `await crypto.subtle.digest('SHA-1', new TextEncoder().encode('hello')).then(b => Array.from(new Uint8Array(b)).map(b => b.toString(16).padStart(2, '0')).join(''))`. Node.js : `crypto.createHash('sha1').update('hello').digest('hex')`. Bash/Unix : `echo -n 'hello' | sha1sum`. Tous produisent la même chaîne hexadécimale de 40 caractères. La distinction chaîne d'octets vs chaîne de texte est importante : `'hello'.encode()` en Python donne des octets ; passer une chaîne ordinaire peut lever une TypeError. Spécifiez toujours explicitement l'encodage d'entrée (typiquement UTF-8) pour le contenu non ASCII.

Qu'est-ce que HMAC-SHA1 et où reste-t-il acceptable ?

HMAC-SHA1 (RFC 2104) combine une clé secrète avec SHA-1 pour produire un code d'authentification de message de 160 bits. Bien que la résistance aux collisions de SHA-1 soit cassée, HMAC-SHA1 reste sûr car HMAC repose sur la propriété de fonction pseudo-aléatoire de la fonction de hachage sous-jacente, et non sur la résistance aux collisions. AWS Signature Version 2 utilisait historiquement HMAC-SHA1 (maintenant déconseillée au profit de Signature Version 4 avec HMAC-SHA256). OAuth 1.0a (RFC 5849) spécifiait HMAC-SHA1 comme méthode de signature. Les applications modernes devraient malgré tout migrer vers HMAC-SHA256 (RFC 4868) ou HMAC-SHA3 car de futures faiblesses dans SHA-1 pourraient affecter HMAC à terme, et le matériel moderne accélère SHA-256 de manière équivalente.

À quoi sert le checksum SHA-1 de fichier ?

Les checksums SHA-1 sont encore largement utilisés pour vérifier l'intégrité de fichiers dans des contextes non adversariaux : téléchargements de distributions Linux (Debian, Ubuntu fournissent SHA1SUMS et SHA256SUMS), manifestes d'images Docker, identifiants de commit GitHub, hashes de pièces BitTorrent et systèmes de stockage adressables par contenu. Ils détectent une corruption accidentelle due aux erreurs disque ou téléchargements partiels mais ne défendent pas contre une altération malveillante. Préférez toujours les checksums SHA-256 lorsqu'ils sont disponibles — la plupart des distributions publient désormais les deux. Pour vérifier : `sha1sum fichier.iso` et comparer à la valeur publiée. La démonstration shattered.io a montré deux PDF fabriqués avec le même SHA-1 mais des contenus différents, donc ne faites confiance à SHA-1 que pour une intégrité non adversariale.

Comment vérifier un téléchargement avec SHA-1 ?

Lorsqu'un projet publie un fichier SHA1SUM (ou .sha1) à côté d'une ISO, d'un paquet ou d'une release, vous confirmez que votre téléchargement est intact en hachant le fichier local et en le comparant à cette valeur publiée. En ligne de commande : `sha1sum ubuntu.iso` affiche une empreinte hexadécimale de 40 caractères suivie du nom du fichier — comparez-la caractère par caractère à la valeur du fichier SHA1SUMS (ou lancez `sha1sum -c SHA1SUMS` pour une vérification automatique). Avec cet outil, choisissez le fichier dans le champ « Ou hacher un fichier » — il est haché localement dans votre navigateur via Web Crypto et n'est jamais envoyé — puis collez le checksum publié dans le champ « Hash attendu ». Vous obtenez un verdict explicite CORRESPOND (somme vérifiée) ou NE CORRESPOND PAS (la somme diffère), sans avoir à comparer 40 caractères hexadécimaux à l'œil. La comparaison ne tient pas compte de la casse et tolère le collage d'une ligne SHA1SUM complète (le nom de fichier final est ignoré). Remarque : une correspondance SHA-1 prouve que le fichier n'a pas été corrompu accidentellement durant le transfert, mais comme la résistance aux collisions de SHA-1 est cassée, préférez le checksum SHA-256 (sha256sum) lorsque le projet publie les deux pour une protection contre une altération délibérée.