Calculer un hash MD5 ou SHA sans se tromper

Vous avez sous les yeux deux chaînes hexadécimales : celle publiée par l'éditeur d'un logiciel et celle que vous venez de calculer. Elles doivent être identiques, caractère pour caractère. Quand ce n'est pas le cas, la cause est presque toujours plus prosaïque qu'une attaque — un retour de ligne en trop, un encodage différent, un algorithme qui n'est pas le bon. Voici comment produire une empreinte fiable, et comment diagnostiquer un écart.

Cinq algorithmes, cinq longueurs

Une fonction de hachage transforme une entrée de taille quelconque en une empreinte de taille fixe. La longueur du résultat identifie donc l'algorithme employé, et c'est déjà un réflexe de diagnostic utile : si on vous fournit 40 caractères et que vous en produisez 64, vous n'utilisez pas la même fonction.

Une empreinte s'écrit indifféremment en majuscules ou en minuscules : D41D8CD9… et d41d8cd9… désignent la même valeur. PowerShell affiche l'hexadécimal en majuscules, sha256sum en minuscules — cette seule différence de casse provoque un nombre déraisonnable de fausses alertes.

Calculer l'empreinte d'un texte

Pour une chaîne, un jeton à comparer, un extrait de configuration, le calculateur MD5 renvoie les 32 caractères attendus et affiche deux compteurs : nombre de caractères et nombre d'octets UTF-8. Ce second chiffre est le plus intéressant des deux, on y revient plus bas. Le calculateur SHA produit simultanément SHA-1, SHA-256, SHA-384 et SHA-512 : plutôt que deviner l'algorithme utilisé en face, vous comparez les quatre d'un coup.

Les deux s'exécutent entièrement dans le navigateur, le texte saisi ne part sur aucun serveur. Cela a une conséquence technique concrète : l'outil SHA s'appuie sur l'API WebCrypto, disponible uniquement en contexte sécurisé. Sur une page ouverte en HTTP simple ou dans un navigateur ancien, il affiche une erreur explicite plutôt qu'un résultat faux.

Vérifier que l'outil dit vrai

Quelques valeurs de référence, issues des jeux de test officiels des algorithmes, permettent de contrôler n'importe quelle implémentation en dix secondes :

• Chaîne vide, MD5 : d41d8cd98f00b204e9800998ecf8427e
• Chaîne vide, SHA-1 : da39a3ee5e6b4b0d3255bfef95601890afd80709
• Chaîne vide, SHA-256 : e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
• Les trois lettres abc, MD5 : 900150983cd24fb0d6963f7d28e17f72
• Les trois lettres abc, SHA-256 : ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Si abc ne vous donne pas 900150983cd24fb0d6963f7d28e17f72, ce n'est pas l'outil qui se trompe : vous avez saisi autre chose que trois lettres. Un espace, une majuscule, un saut de ligne.

Pourquoi deux empreintes du même contenu diffèrent

Un hachage porte sur des octets, jamais sur ce que vous voyez à l'écran. Un seul bit modifié change environ la moitié des bits du résultat : il n'existe pas d'écart « léger », deux empreintes concordent ou n'ont rien en commun. Les coupables habituels, par fréquence décroissante :

• Le saut de ligne final. La plupart des éditeurs terminent un fichier texte par un retour à la ligne. Le mot secret seul et le même mot suivi d'un saut de ligne donnent deux empreintes sans rapport. C'est la première cause d'écart sur les chaînes courtes copiées depuis un terminal.
• CRLF contre LF. Un fichier passé par Windows contient les octets 0D 0A là où l'original n'avait que 0A. Sur 500 lignes, cela fait 500 octets d'écart. Git opère la conversion à la volée selon le réglage core.autocrlf, ce qui explique des empreintes divergentes entre deux clones du même dépôt.
• Le BOM UTF-8. Trois octets invisibles, EF BB BF, ajoutés en tête de fichier par le Bloc-notes ou par un export tableur. Le contenu s'affiche à l'identique, l'empreinte n'a plus rien à voir.
• L'encodage. Le caractère é vaut un octet en ISO-8859-1 (E9) et deux en UTF-8 (C3 A9). Sur un texte français de 2 000 mots, l'écart se compte en centaines d'octets, pour un contenu visuellement identique.
• La normalisation Unicode. Le é peut être un caractère précomposé (U+00E9) ou la lettre e suivie d'un accent combinant (U+0301). Même rendu, deux séquences d'octets. macOS stocke traditionnellement les noms de fichiers sous forme décomposée, ce qui piège les comparaisons entre systèmes.
• Les caractères parasites. Espace insécable collé depuis un traitement de texte, tabulation transformée en espaces, apostrophe courbe substituée à l'apostrophe droite, espace en fin de ligne.

Le diagnostic en trois étapes

1. Collez successivement les deux versions du texte dans le calculateur MD5 et comparez le compteur d'octets UTF-8. Deux valeurs différentes pour un même nombre de caractères affichés : le problème est un encodage ou un caractère invisible.
2. Nombre d'octets identique mais empreintes différentes : un caractère a bien été remplacé. Cherchez du côté des guillemets typographiques, tirets longs et apostrophes courbes insérés automatiquement.
3. Supprimez le dernier caractère si c'est un saut de ligne, recalculez. Dans la majorité des cas l'écart disparaît là.

Pour un fichier, passez par votre système

Les calculateurs en ligne travaillent sur du texte saisi ou collé. Pour l'empreinte d'une image disque de 4 Go ou d'un installeur de 300 Mo, la commande locale est plus rapide, évite tout transfert et lit le fichier tel qu'il est réellement sur le disque :

• Windows, PowerShell : Get-FileHash fichier.iso -Algorithm SHA256
• Windows, invite de commandes : certutil -hashfile fichier.iso SHA256
• macOS : shasum -a 256 fichier.iso ou md5 fichier.iso
• Linux : sha256sum fichier.iso ou md5sum fichier.iso
• Contrôler tout un lot depuis un fichier de sommes fourni : sha256sum -c sommes.sha256

Ne comparez pas 64 caractères à l'œil. Vérifier les six premiers et les six derniers caractères est une habitude répandue et insuffisante : une collision fabriquée volontairement n'a aucune raison d'être repérée ainsi. Superposez les deux valeurs dans un éditeur, ou laissez la commande de vérification trancher.

Ce qu'une empreinte ne prouve pas

Elle établit qu'un contenu correspond à une référence. Elle ne dit rien de l'origine de cette référence. Si le fichier et son empreinte sont publiés au même endroit, quiconque remplace l'un remplace l'autre : la vérification devient un rituel sans effet. L'empreinte de référence doit venir d'un canal distinct, idéalement accompagnée d'une signature.

Sur la solidité des algorithmes, les faits sont établis. Des collisions MD5 se fabriquent en quelques secondes sur une machine ordinaire depuis les travaux publiés en 2004. SHA-1 est tombé en 2017, avec la diffusion de deux fichiers PDF différents partageant la même empreinte, puis en 2020 avec une attaque à préfixe choisi, bien plus exploitable en pratique. Conclusion : MD5 et SHA-1 restent utiles pour repérer une corruption accidentelle, un transfert interrompu ou un doublon. Ils ne valent rien face à quelqu'un qui cherche à vous tromper. Dans ce second cas, SHA-256.

Une empreinte n'est pas non plus un secret. Le MD5 d'un mot courant se retrouve en une recherche, des tables entières sont publiées depuis des années. C'est pourquoi hacher un mot de passe en MD5 ou en SHA-256 ne le protège pas : ces fonctions sont conçues pour être rapides, donc pour être testées des milliards de fois par seconde. Le stockage de mots de passe réclame bcrypt, scrypt ou Argon2, avec un sel unique par compte. Et en amont, la longueur et le caractère aléatoire du mot de passe — ce que produit le générateur de mot de passe — pèsent plus lourd que le choix de la fonction.

Enfin, hacher n'est pas chiffrer. L'opération est à sens unique, il n'existe pas de « déhachage » : les sites qui prétendent décrypter un MD5 interrogent en réalité une table de valeurs déjà calculées. La confusion la plus fréquente porte sur le Base64, qui ressemble à du charabia mais se lit dans les deux sens, comme l'encodeur et décodeur Base64 le montre en un clic. Un mot de passe encodé en Base64 dans un fichier de configuration est un mot de passe en clair.

À retenir

• Longueur inattendue : ce n'est pas le bon algorithme.
• Empreintes différentes sur un texte apparemment identique : saut de ligne final, BOM, encodage.
• Enjeu de sécurité : SHA-256, avec une empreinte de référence obtenue par un autre canal que celui qui héberge le fichier.
• Mot de passe : ni MD5 ni SHA, jamais.

Les deux calculateurs de Convertu tournent dans l'onglet : ni le texte ni son empreinte ne quittent votre machine, ce qui est la moindre des choses quand on hache une clé d'API pour la comparer.