Générateur de hash SHA

À quoi sert un hash

Un hash cryptographique transforme n’importe quelle entrée en une empreinte de longueur fixe. La même entrée produit toujours le même condensat, et la modification d’un seul caractère en produit un complètement différent — ce qui rend les hash parfaits pour vérifier l’intégrité d’un fichier, comparer des contenus, dédoublonner des données et signer numériquement. Le hachage est à sens unique : il est impossible de retrouver le texte d’origine à partir du hash.

Quel algorithme choisir ?

Pour tout ce qui touche à la sécurité, utilisez SHA-256 ou plus. SHA-1 et MD5 sont cassés sur le plan cryptographique et ne doivent pas servir à protéger des données. Et n’oubliez pas : les mots de passe exigent un hachage lent et salé (bcrypt / scrypt / Argon2), jamais un simple condensat SHA.

Ce qui rend un hash « cryptographique »

Beaucoup de fonctions brouillent les données, mais une fonction de hachage cryptographique comme SHA-256 est conçue pour respecter un ensemble précis de garanties mathématiques. Les comprendre, c’est faire la différence entre utiliser un hash correctement et lui confier une tâche pour laquelle il n’a jamais été prévu.

• Déterministe. La même entrée donne toujours exactement le même condensat — sur n’importe quelle machine, dans n’importe quel langage de programmation, aujourd’hui comme dans dix ans. C’est ce qui permet à deux personnes de comparer un fichier en comparant 64 caractères hexadécimaux plutôt que le fichier entier.
• Sortie de taille fixe. Un mot de trois lettres et un film de trois gigaoctets donnent un hash de même longueur (256 bits pour SHA-256). L’entrée peut avoir n’importe quelle taille ; le condensat, lui, ne grandit jamais.
• Rapide à calculer. Produire un condensat est peu coûteux et rapide. C’est un atout pour les contrôles d’intégrité, mais un handicap pour le stockage des mots de passe — c’est précisément pour cela que les mots de passe exigent une fonction volontairement lente, comme indiqué plus haut.
• Résistance à la préimage (sens unique). À partir d’un condensat seul, il est irréalisable en pratique de trouver une entrée quelconque qui le produise. On ne peut pas « déhacher » une valeur pour revenir à sa source — il n’existe pas de bouton « déchiffrer », puisque rien n’a jamais été chiffré.
• Résistance à la seconde préimage. À partir d’un fichier donné, il est irréalisable de fabriquer un fichier différent ayant le même condensat — un attaquant ne peut donc pas remplacer discrètement un téléchargement par une version piégée qui correspondrait encore au hash publié.
• Résistance aux collisions. Il est irréalisable de trouver deux entrées distinctes quelconques qui partagent le même condensat. C’est cette propriété qui a cédé pour MD5 et SHA-1 (voir plus bas).
• L’effet avalanche. Inversez un seul bit de l’entrée et environ la moitié des bits de sortie s’inversent aussi, sans motif visible. « cat » et « cot » donnent des condensats sans aucun rapport, si bien qu’un hash ne révèle rien sur la ressemblance entre deux entrées.

Remarque : l’effet avalanche est un objectif de conception qui donne au hash une apparence aléatoire ; les résistances à la préimage, à la seconde préimage et aux collisions sont les trois propriétés de sécurité formelles sur lesquelles les cryptographes raisonnent réellement.

Les tailles de condensat en un coup d’œil

Le nombre qui suit « SHA » est la longueur du condensat en bits. Comme chaque caractère hexadécimal code 4 bits, la chaîne hexadécimale compte toujours un nombre de caractères égal à la longueur en bits divisée par quatre — un moyen rapide de reconnaître l’algorithme qui a produit un hash, simplement en comptant les caractères.

Une brève histoire de SHA

La famille Secure Hash Algorithm est publiée par l’Institut national américain des normes et de la technologie (NIST), et la chronologie explique pourquoi certains membres sont dignes de confiance et d’autres mis à la retraite :

• MD5 (1991). Conçu par Ronald Rivest et publié sous la référence RFC 1321 en 1992. Un condensat de 128 bits qui fut le cheval de bataille des années 1990 — et qui est aujourd’hui complètement cassé.
• SHA-0 (1993). Le « SHA » d’origine, publié dans FIPS 180, a été retiré par le NIST peu après sa publication, à la demande de la NSA, une fois une faille importante découverte.
• SHA-1 (1995). Le remplaçant corrigé (FIPS 180-1), sur 160 bits. Il est devenu omniprésent dans les certificats TLS, Git et la signature de logiciels avant de tomber sous les attaques.
• SHA-2 (2002). La famille standard actuelle — SHA-256, SHA-384 et SHA-512 (FIPS 180-2), SHA-224 ayant été ajouté en 2004. Toujours considérée comme sûre, et le choix par défaut aujourd’hui.
• SHA-3 / Keccak (2015). Lauréat d’un concours public du NIST en 2012, normalisé sous la référence FIPS 202. Point essentiel : il repose sur une conception interne entièrement différente (une « éponge ») au lieu de la construction de Merkle–Damgård de MD5/SHA-1/SHA-2, si bien qu’une attaque contre une famille ne se transpose pas à l’autre.

Ces nombres sont-ils vraiment si grands ?

Les affirmations de sécurité comme « irréalisable » reposent sur la taille colossale de l’espace de recherche. À cause du paradoxe des anniversaires, trouver une collision quelconque dans un hash de n bits demande environ 2^n/2 essais — la résistance aux collisions vaut donc en pratique la moitié de la longueur du condensat. Pour SHA-256, cela représente environ 2¹²⁸ opérations : un nombre bien plus grand que ce que tous les ordinateurs jamais construits pourraient traiter pendant toute la durée de vie de l’univers. C’est cette marge qui fait qu’un condensat de 256 bits reste confortable pour l’avenir prévisible, alors qu’un condensat de 160 bits (SHA-1) ne l’est plus.

Quand les hash cèdent : les attaques par collision

« Cassé » n’est pas une figure de style — le mot renvoie à des attaques précises et publiées, qui ont trouvé de vraies collisions :

• MD5 — 2004. Xiaoyun Wang et ses collègues ont démontré des collisions pratiques, mettant fin à la carrière de MD5 comme primitive de sécurité.
• MD5 — exploité en conditions réelles, 2012. Le logiciel espion Flame a utilisé une collision MD5 à préfixe choisi pour forger un certificat de signature de code Microsoft et se faire passer pour une mise à jour légitime de Windows Update — un exemple d’école montrant qu’un hash cassé est dangereux, et pas seulement en théorie.
• SHA-1 — « SHAttered », février 2017. Des chercheurs de Google et du CWI Amsterdam ont produit deux fichiers PDF différents ayant le même hash SHA-1, la première collision pratique, pour un coût d’environ 2⁶³ calculs. Une collision à préfixe choisi, encore plus puissante, a suivi en 2020.
• SHA-1 — officiellement retiré. En décembre 2022, le NIST a annoncé qu’il éliminerait SHA-1 de tous les usages d’ici le 31 décembre 2030, en orientant chacun vers SHA-2 ou SHA-3.

MD5 et SHA-1 produisent encore des empreintes stables et utiles pour détecter une corruption accidentelle — mais comme un attaquant peut fabriquer des collisions, on ne peut se fier à aucun des deux dès qu’un adversaire peut entrer en jeu.

L’extension de longueur, et pourquoi HMAC existe

MD5, SHA-1 et SHA-2 construisent tous leur condensat avec la construction de Merkle–Damgård, en traitant le message bloc par bloc. Un effet secondaire en est l’attaque par extension de longueur : si vous authentifiez naïvement un message avec hash(secret + message), quiconque voit ce condensat peut ajouter des données à la fin et calculer un hash valide pour le message rallongé sans jamais connaître le secret. C’est pourquoi il ne faut jamais bricoler son propre hachage à clé. Utilisez HMAC (qui imbrique la clé et n’est pas vulnérable), ou SHA-3, dont la construction en éponge n’y est tout simplement pas vulnérable. Parmi les membres de SHA-2, les variantes tronquées SHA-384 et SHA-512/256 résistent elles aussi à l’extension de longueur, alors que SHA-256 et SHA-512 n’y résistent pas.

À quoi servent vraiment les hash

Au-delà de l’évident « vérifier un téléchargement », le hachage cryptographique soutient discrètement une part énorme de l’informatique moderne :

• Intégrité des fichiers et sommes de contrôle — les éditeurs publient un SHA-256 à côté d’un téléchargement pour que vous puissiez confirmer que les octets reçus sont bien ceux qu’ils ont envoyés.
• Signatures numériques — on signe le hash court d’un document, et non le document entier, ce qui rend rapide la signature de gros fichiers.
• Authentification de messages (HMAC) — prouver qu’un message vient bien de la personne attendue et n’a pas été modifié, à l’aide d’une clé partagée.
• Stockage des mots de passe — au moyen d’une fonction de dérivation de clé volontairement lente et d’un sel (bcrypt / scrypt / Argon2), jamais d’un simple SHA.
• Dédoublonnage — des contenus identiques ont des hash identiques, si bien qu’un système de sauvegarde ou de stockage peut n’en garder qu’une seule copie.
• Adressage par le contenu — Git nomme chaque commit et chaque fichier par son hash (historiquement SHA-1, avec une migration en cours vers SHA-256), et IPFS adresse les contenus par leur condensat, si bien que l’adresse est le contrôle d’intégrité.
• Preuve de travail — les mineurs Bitcoin hachent sans relâche un en-tête de bloc (avec un double SHA-256) à la recherche d’un condensat inférieur à une cible ; l’effet avalanche est ce qui rend cette recherche équitable et imprévisible.
• Schémas d’engagement — publiez hash(value) maintenant pour figer un choix, puis révélez la valeur plus tard pour prouver que vous n’avez pas changé d’avis.

Sels, tables arc-en-ciel et poivres

Une table arc-en-ciel est une gigantesque table de correspondance précalculée qui inverse presque instantanément les hash non salés — si un site stockait un simple SHA-256(password), une base de données volée pourrait donc être cassée en quelques minutes. Un sel déjoue cette attaque : une valeur aléatoire unique, mélangée à chaque mot de passe avant le hachage, fait que deux utilisateurs ayant le même mot de passe obtiennent des condensats différents, et une table précalculée devrait être reconstruite pour chaque sel — ce qui est irréalisable. Le sel est stocké avec le hash et n’est pas secret. Un poivre va encore plus loin : une valeur secrète unique, conservée en dehors de la base de données (dans la configuration de l’application ou dans un module matériel) et mélangée elle aussi, de sorte qu’un attaquant qui ne vole que la base de données ne peut toujours pas tester des mots de passe candidats. Cette défense en couches est celle qu’utilise un vrai système de connexion — et la raison pour laquelle un simple condensat SHA ne suffit jamais pour des mots de passe.

Une somme de contrôle n’est pas un hash cryptographique

Il vaut la peine de distinguer deux notions qui se ressemblent. Une somme de contrôle comme CRC32 est conçue pour détecter une corruption accidentelle — un bit inversé sur un réseau bruité — et elle le fait à peu de frais. Mais CRC32 est linéaire et trivialement manipulable : un attaquant peut modifier un fichier puis recalculer un CRC parfaitement valide, si bien qu’il n’offre aucune résistance à la falsification. Pour détecter une modification délibérée, il vous faut un hash cryptographique comme SHA-256, pas une somme de contrôle. Cet outil s’appuie sur l’API Web Crypto intégrée à votre navigateur (crypto.subtle.digest), qui ne propose que SHA-1, SHA-256, SHA-384 et SHA-512 — MD5 n’en fait pas partie.

Hachage, encodage et chiffrement — trois choses différentes

Ces trois mots sont sans cesse confondus, et cette confusion provoque de vrais bogues. Ils ne sont pas interchangeables :

• Le hachage est à sens unique et déterministe. Vous pouvez produire un condensat à partir de données, mais pas retrouver les données à partir du condensat. Son but est de vérifier, non de stocker ou de cacher. Le hash SHA-256 de « password » est le même pour tout le monde et ne révèle rien — mais il ne peut pas non plus être inversé.
• L’encodage (comme Base64 ou l’encodage d’URL) est une transformation réversible destinée au transport sans risque — n’importe qui peut le décoder. Il n’apporte aucune confidentialité ; il se contente de reconditionner les données dans un autre jeu de caractères.
• Le chiffrement est réversible avec une clé. Il est conçu pour garder les données secrètes vis-à-vis de quiconque ne possède pas cette clé, et le texte chiffré se déchiffre pour redonner exactement le texte en clair d’origine. C’est le seul des trois qui sert à protéger la confidentialité.

Donc si quelqu’un affirme avoir « haché le numéro de carte bancaire pour qu’il soit chiffré », il commet une erreur de catégorie : un hash n’est pas un chiffrement et ne peut pas être déchiffré. Utilisez le hachage pour confirmer que quelque chose n’a pas changé, l’encodage pour faire transiter des données sans risque par un canal texte, et le chiffrement quand vous avez réellement besoin de garder un secret.

Comment vérifier un téléchargement avec son hash

L’usage quotidien le plus courant de cet outil consiste à vérifier qu’un fichier téléchargé est authentique et intact. De nombreux projets publient le SHA-256 de leurs installateurs et de leurs versions précisément pour que vous puissiez le faire :

1. Trouvez le hash officiel publié par l’éditeur à côté du téléchargement (souvent intitulé « SHA-256 » ou « checksum »).
2. Calculez le SHA-256 du fichier que vous avez réellement reçu — en ligne de commande avec shasum -a 256 fichier (macOS / Linux) ou certutil -hashfile fichier SHA256 (Windows), ou en collant du texte dans l’outil ci-dessus.
3. Comparez les deux chaînes. Si elles correspondent exactement, caractère par caractère, votre copie est identique bit à bit à ce que l’éditeur a publié.

Un seul caractère différent signifie que le fichier est différent — il a pu être corrompu pendant le transfert, ou falsifié. Grâce à l’effet avalanche, même la modification d’un seul octet produit un condensat complètement différent : cette vérification est donc à la fois simple et puissante. Gardez seulement sa limite en tête : une somme de contrôle prouve uniquement que le fichier correspond au hash publié — vous devez encore avoir confiance dans le fait que ce hash provient d’une source légitime, via une page sécurisée (HTTPS).

Questions fréquentes

Un hash est-il la même chose qu’un chiffrement ?

Non. Un hash cryptographique est à sens unique : il transforme n’importe quelle entrée en une empreinte de taille fixe qu’il est impossible de ramener à l’original. Le chiffrement fonctionne dans les deux sens (on peut déchiffrer avec une clé). Utilisez le hachage pour les contrôles d’intégrité et les empreintes, pas pour « cacher » des données que vous devrez récupérer.

Puis-je utiliser cet outil pour stocker des mots de passe ?

Pas avec un simple hash SHA. Les mots de passe doivent être stockés avec une fonction de hachage de mots de passe lente et salée, comme bcrypt, scrypt ou Argon2 — jamais avec un SHA-256 nu ni, pire encore, avec MD5. Les hash rapides sont conçus pour être rapides, ce qui est exactement ce que vous ne voulez pas pour des mots de passe.

Pourquoi MD5 n’est-il pas proposé ici ?

MD5 (et SHA-1) sont cassés sur le plan cryptographique — des attaques par collision pratiques existent —, ils ne doivent donc pas servir à la sécurité. Nous nous concentrons sur SHA-256 et au-delà. SHA-1 n’est inclus que pour les vérifications d’intégrité avec d’anciens systèmes, et il est clairement signalé.

Mon texte quitte-t-il le navigateur ?

Non. Le hachage utilise l’API Web Crypto intégrée à votre navigateur : le texte est traité localement et n’est jamais envoyé. Une fois la page chargée, l’outil fonctionne même hors ligne.

Outils associés

• Générateur d’UUID
• Encoder et décoder Base64
• Texte en hexadécimal
• Formateur et validateur JSON
• Encoder et décoder une URL

Voir toutes les conversions pour les développeurs et les données →