Génération de hachages en ligne, gratuite

Ce qu'est réellement une fonction de hachage cryptographique

Une fonction de hachage cryptographique prend une entrée de taille quelconque et produit une sortie de taille fixe appelée empreinte, condensé ou hash. La même entrée produit toujours le même hash ; un changement d'un seul bit en entrée produit un hash radicalement différent (l'« effet d'avalanche ») ; et la fonction est calculatoirement infaisable à inverser, étant donné un hash, vous ne pouvez pas en pratique retrouver l'entrée qui l'a produit. Trois propriétés de résistance rendent une fonction « cryptographique » : la résistance à la préimage (étant donné un hash h, infaisable de trouver une entrée m telle que hash(m) = h), la résistance à la seconde préimage (étant donné m₁, infaisable de trouver un autre m₂ de même hash), et la résistance aux collisions (infaisable de trouver deux entrées distinctes de même hash). Une fonction qui perd la résistance aux collisions peut rester sûre pour certains usages (intégrité de fichier) mais pas pour d'autres (signatures numériques). MD5 et SHA-1 sont exactement dans cette catégorie : leurs collisions sont cassées, mais leur préimage tient.

Une brève histoire de MD5, SHA-1, SHA-2 et SHA-3

MD2 / MD4 / MD5 sont l'œuvre de Ron Rivest au MIT et chez RSA Data Security. MD2 a été publié en 1989 ; MD4 en 1990 ; MD5 a été publié en 1991 et standardisé sous RFC 1321 en avril 1992. MD5 a été le hash dominant pendant une décennie, défaut pour les checksums de téléchargement, le stockage de mots de passe, la déduplication de fichiers et les systèmes adressables par contenu. Le premier coup de semonce a retenti en 1995, quand Hans Dobbertin a publié une attaque par collision en rondes complètes sur MD4, le prédécesseur de MD5 ; la première collision pratique sur MD5 complet est arrivée en août 2004, quand Wang et Yu ont annoncé deux messages de 128 octets en collision ; Vlastimil Klima a fait passer la recherche de collisions MD5 de plusieurs heures à quelques secondes sur du matériel grand public en 2006. Marc Stevens, en collaboration avec des chercheurs de TU Eindhoven et de l'EPFL, a démontré une collision MD5 à préfixe choisi au 25C3 en décembre 2008, en produisant un certificat CA RapidSSL falsifié. Au moment du malware Flame en 2012, qui a utilisé une collision MD5 pour falsifier les certificats Microsoft Update, MD5 était totalement cassé pour tout usage sensible à la sécurité.

SHA (« Secure Hash Algorithm ») est une famille de la NSA américaine. SHA-0 a été publié comme FIPS 180 en mai 1993 et retiré dans l'année pour des défauts de conception non précisés. SHA-1 a suivi sous FIPS 180-1 en avril 1995, avec un changement d'un bit dans le schedule de message que la NSA n'a jamais publiquement expliqué. SHA-1 est devenu le hash par défaut de la fin des années 1990 et des années 2000, utilisé par Git pour les hashes de commit, par les certificats SSL/TLS, par pratiquement chaque schéma de signature. La première attaque par collision théorique est arrivée en 2005 (Wang, Yin, Yu) ; une collision freestart en 2015 (Stevens, Karpman, Peyrin) ; et la première collision SHA-1 complète a été livrée le 23 février 2017 sous le nom « SHAttered » (Stevens, Bursztein, Karpman, Albertini, Markov), qui a produit deux fichiers PDF différents avec le même hash SHA-1. En janvier 2020, l'attaque « SHA-1 is a Shambles » à préfixe choisi (Leurent et Peyrin, coût total environ 45 000 USD de location de GPU) a rendu la falsification de certificats abordable, accélérant la transition vers SHA-256 que le projet Git avait déjà commencé à planifier en 2018. SHA-1 est désormais formellement déprécié par le NIST pour les signatures numériques et les certificats.

SHA-2 est la famille qui a remplacé SHA-1 : SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256, publiés sous FIPS 180-2 en août 2002. SHA-2 était une conception défensive, sorties plus grandes, plus de tours, état interne plus large, et vingt-trois ans plus tard, il reste incassé. SHA-256 est le défaut moderne pour les signatures numériques, les certificats, les JWT, les hashes de bloc Bitcoin, le stockage adressable par contenu, et la majorité des vérifications d'intégrité de fichier. SHA-3 est une conception fondamentalement différente, la construction éponge Keccak par Bertoni, Daemen, Peeters et Van Assche, sélectionnée à l'issue d'une compétition NIST de cinq ans ouverte en 2007 et remportée par Keccak en octobre 2012 ; publiée sous FIPS 202 en août 2015. SHA-3 n'est pas un remplaçant de SHA-2 (SHA-2 est encore sûr) ; c'est une alternative défensive avec une structure interne complètement différente, de sorte qu'une cassure cryptanalytique future de SHA-2 ne toucherait pas nécessairement SHA-3. Cet outil produit SHA-1, SHA-256, SHA-384 et SHA-512 (l'ensemble pris en charge par la Web Crypto API) plus MD5 (via une implémentation JavaScript, puisque la Web Crypto API omet délibérément MD5).

Comparaison des algorithmes

Algorithme	Sortie	Sécurité
MD5	128 bits (32 caractères hex)	Cassé · à proscrire pour la sécurité
SHA-1	160 bits (40 caractères hex)	Faible · obsolète
SHA-256	256 bits (64 caractères hex)	Robuste · recommandé
SHA-384	384 bits (96 caractères hex)	Robuste
SHA-512	512 bits (128 caractères hex)	Robuste

Où apparaissent les hashes cryptographiques

• Intégrité de fichier / checksums. Les miroirs de distributions Linux publient des hashes SHA-256 (et historiquement MD5/SHA-1) à côté des téléchargements ISO ; l'utilisateur calcule le hash du fichier téléchargé et le compare à la valeur publiée. Une différence signifie que le téléchargement a été corrompu ou altéré. shasum, sha256sum et md5sum sont les outils Unix standards.
• Stockage de mots de passe, mais JAMAIS comme hash brut. Stocker SHA-256(mot_de_passe) tel quel est dangereux parce que les rainbow tables (cartes précalculées (mot de passe → hash)) rendent les hashes bruts réversibles en millisecondes. Le bon motif est une fonction de hachage de mot de passe (KDF) avec un sel par utilisateur et un facteur de coût ajustable : Argon2id (RFC 9106, 2021, recommandation moderne), scrypt (RFC 7914, Percival 2009) ou bcrypt (Provos et Mazières, USENIX 1999). Tous trois combinent un sel (pour que des mots de passe identiques produisent des hashes stockés différents) avec un calcul délibérément coûteux (pour que les attaques par force brute soient bridées par le coût matériel). Cet outil calcule des hashes bruts, utiles pour beaucoup de choses, mais inadaptés au stockage de mots de passe seul.
• Signatures numériques. On signe le hash, pas la donnée, la donnée est trop longue à signer efficacement. RSA, DSA, ECDSA et EdDSA signent tous un hash du message. La fonction de hachage utilisée doit être résistante aux collisions (sinon un attaquant peut substituer un message en collision) ; c'est exactement pour cela que MD5 et SHA-1 sont dépréciés pour les signatures.
• Stockage adressable par contenu de Git. Chaque objet Git (blob, tree, commit, tag) est identifié par le SHA-1 de son contenu. Le choix de conception de Linus Torvalds en 2005 est aujourd'hui en pleine transition pluriannuelle vers SHA-256, motivée par la cassure des collisions de SHA-1. Git for Windows et Git officiel proposent tous deux le support SHA-256 ; la migration en production est progressive.
• Bitcoin et Ethereum. Bitcoin utilise un double-SHA-256 pour les hashes de bloc et les identifiants de transaction (la fonction de hachage domine le coût du minage Bitcoin, des ASIC existent uniquement pour calculer SHA-256 vite). Ethereum utilise Keccak-256 (le Keccak originel avant les ajustements de standardisation NIST ; parfois appelé « SHA-3 moins le changement de padding »).
• Vérification de signature JWT. Les JSON Web Tokens sont typiquement signés avec HMAC-SHA-256 (nom d'algorithme « HS256 » dans la spec JWT) ou avec RSA/ECDSA sur un hash SHA-256. La signature permet au destinataire de vérifier que le jeton vient bien de l'émetteur et n'a pas été altéré.
• Subresource Integrity (SRI). L'attribut integrity="sha256-..." sur les balises <script> et <link> permet aux navigateurs de vérifier qu'un script hébergé par CDN n'a pas été modifié avant de l'exécuter, défense contre les CDN compromis.
• Signature de requêtes API. AWS Signature Version 4 utilise HMAC-SHA-256 pour signer chaque requête API avec la clé secrète d'accès de l'utilisateur. Cela authentifie la requête sans envoyer le secret sur le réseau et évite les attaques par rejeu via l'horodatage.

Cassure des collisions vs cassure de la préimage, pourquoi MD5 est encore utilisé

Confusion fréquente : si MD5 est « cassé », pourquoi md5sum est-il toujours dans toute distrib Linux ? La réponse est la distinction entre résistance aux collisions (cassée pour MD5) et résistance à la préimage (toujours intacte pour MD5). Une attaque par collision permet à un attaquant de construire deux entrées différentes ayant le même hash ; cela compte pour les signatures numériques (où un attaquant peut fabriquer une paire en collision, en faire signer une, puis substituer l'autre) et pour toute application où la fonction est censée lier un input précis. Une attaque par préimage, en revanche, permettrait à un attaquant de retrouver l'input original à partir d'un hash, c'est ce qui casserait réellement un checksum de téléchargement, un hash de mot de passe ou un identifiant adressable par contenu. La résistance à la préimage de MD5 n'a pas été cassée ; les meilleures attaques par préimage publiées restent proches de la borne théorique 2¹²⁸, calculatoirement infaisables sur tout matériel existant ou attendu. Donc MD5 (et SHA-1) restent légitimes pour : la vérification d'intégrité de fichier quand vous faites confiance à la source du hash publié (un attaquant qui peut substituer le fichier peut vraisemblablement aussi substituer le hash, le modèle de menace est donc « corruption accidentelle » et non « altération délibérée ») ; les clés de cache et la déduplication où vous contrôlez les deux extrémités ; les constructions HMAC (HMAC-MD5 reste sûr parce que la structure de HMAC est robuste face à la faiblesse de collision de MD5, même si HMAC-SHA-256 est préféré pour le code récent). Là où MD5 doit être remplacé : signatures numériques, hashes de certificat, partout où un attaquant peut fabriquer l'input.

La Web Crypto API et l'omission délibérée de MD5

Les navigateurs modernes exposent le hachage via crypto.subtle.digest(algorithm, data), une fonction asynchrone qui renvoie le hash sous forme d'ArrayBuffer. Algorithmes pris en charge : SHA-1, SHA-256, SHA-384, SHA-512. Notez ce qui n'y est pas : MD5 est délibérément omis. Le W3C Web Crypto Working Group a fait le choix explicite de laisser MD5 dehors, en estimant que tout usage de MD5 dans un navigateur était soit du legacy (mieux géré avec un polyfill) soit erroné (à ne pas faciliter). Le support MD5 de cet outil vient d'une petite implémentation JavaScript (~10 Ko) embarquée dans la page ; tout le reste (SHA-1, SHA-256, SHA-384, SHA-512, plus toutes les variantes HMAC) passe par Web Crypto pour un traitement à vitesse native. La Web Crypto API n'est disponible qu'en contextes sécurisés (HTTPS ou localhost), ouvrir cet outil en HTTP simple désactiverait silencieusement le hachage SHA.

Formats de sortie : Hex, Base64, Base32

Les hashes sont binaires par nature, un hash de 256 bits est 32 octets de données opaques. Pour les afficher ou les transporter, on les encode en texte. Hex (Base16) est l'encodage le plus courant : chaque octet devient deux caractères hex, donc une sortie SHA-256 fait 64 caractères hex. Universel, lisible, double la taille. Base64 empile les octets plus densément (3 octets → 4 caractères) ; SHA-256 en Base64 fait 44 caractères (avec padding) ou 43 (sans). Utilisé en JWT (la signature est encodée en Base64URL), dans les attributs integrity SRI, et partout où la compacité compte. Base32 (RFC 4648) utilise 32 caractères qui excluent ceux visuellement ambigus (pas de distinction 0/O, 1/I/L) ; utilisé pour les clés secrètes TOTP, les ULID et les adresses onion. Cet outil produit du hex par défaut, le format universel que tout autre outil comprend.

HMAC, hachage à clé pour l'authentification

HMAC (Hash-based Message Authentication Code) est une construction définie dans RFC 2104 (Krawczyk, Bellare, Canetti, février 1997) qui transforme toute fonction de hachage cryptographique en code d'authentification à clé. La construction est HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), où K' est une clé dérivée du secret K, et opad/ipad sont des pads XOR fixes. La structure est prouvablement sûre tant que le hash sous-jacent l'est, et notamment reste sûre même quand le hash sous-jacent a une résistance aux collisions faible (raison pour laquelle HMAC-MD5 est encore considéré sûr, et pour laquelle HMAC-SHA1 reste OK en TLS même après la cassure des collisions de SHA-1). HMAC a trois usages principaux : signature de requêtes API (AWS Signature v4, webhooks GitHub, webhooks Stripe), où le destinataire vérifie que la requête vient bien du détenteur du secret ; intégrité JWT (HS256 = HMAC-SHA-256) ; et dérivation de clé fondée sur mot de passe (PBKDF2 utilise HMAC en interne). Le mode HMAC de cet outil prend une clé secrète et produit le HMAC de l'entrée sous cette clé.

Périmètre honnête : à quoi sert et ne sert pas cet outil

Cet outil calcule des hashes cryptographiques bruts d'un texte ou d'un fichier d'entrée. Utile pour : vérifier des téléchargements de fichiers contre des checksums publiés, générer des identifiants adressables par contenu, calculer des valeurs HMAC pour déboguer une API, comparer l'intégrité de deux copies d'un fichier, et apprendre à quoi hashe un input précis. Pas utile pour : le stockage de mots de passe (utilisez une vraie fonction de hachage de mot de passe comme Argon2id, scrypt ou bcrypt avec sel et facteur de coût appropriés) ; inverser des hashes (c'est l'idée même des fonctions de hachage et c'est impossible par conception) ; ou générer des hashes SHA-3 / Keccak (cet outil produit aujourd'hui SHA-1, SHA-256, SHA-384 et SHA-512 de la famille SHA-2, plus MD5, SHA-3 est sur la liste des futures fonctionnalités) ; générer des hashes BLAKE2 ou BLAKE3. Pour BLAKE3 (le hash moderne à haut débit pour le stockage adressable par contenu), utilisez le CLI dédié ; pour le stockage de mots de passe, utilisez directement la bibliothèque bcrypt/scrypt/Argon2id de votre application.

Vie privée : pourquoi navigateur uniquement compte ici

Hasher un fichier sur un serveur exige de l'envoyer. Pour la vérification de téléchargements ordinaire c'est sans objet, vous faites déjà confiance à la source. Pour hasher des documents internes, des pièces d'identité numérisées, des captures d'interfaces en cours, ou tout fichier que vous ne voudriez pas voir copié sur le disque dur d'un inconnu, le hachage côté serveur est une fuite. Cet outil lit le fichier directement dans votre navigateur via la File API et le hashe localement, rien ne quitte votre appareil. Vérifiez en ouvrant l'onglet Network des DevTools pendant que vous cliquez sur Hacher, ou mettez la page hors ligne (mode avion) après son chargement et confirmez que l'outil fonctionne toujours. La Web Crypto API exige HTTPS mais ne réclame pas d'accès réseau à l'exécution.

Questions fréquentes

À quoi sert MD5 s'il est cassé ?

MD5 reste largement utilisé à des fins non sécuritaires : vérification de l'intégrité des fichiers (contrôle des téléchargements), déduplication, clés de cache et sommes de contrôle. Il ne doit jamais être utilisé pour le hachage des mots de passe, ni pour des signatures numériques.

Puis-je inverser un hachage pour retrouver le texte d'origine ?

Non. Les fonctions de hachage sont conçues pour être à sens unique. Cependant, les attaquants utilisent des tables précalculées (tables arc-en-ciel) pour retrouver des hachages courants. C'est pourquoi les mots de passe doivent être hachés avec des fonctions lentes et salées comme bcrypt, et non avec du SHA-256 brut.

Mon fichier est-il envoyé lorsque je le hache ?

Non. Le fichier est lu directement dans votre navigateur via la File API, puis haché localement via la Web Crypto API (pour SHA) ou une implémentation JavaScript pure (pour MD5). Rien n'est envoyé à un serveur.

Quelle est la différence entre SHA-256 et SHA-3 ?

SHA-256 fait partie de la famille SHA-2 (FIPS 180-2, août 2002), construction Merkle-Damgård, conçue par la NSA. SHA-3 (FIPS 202, août 2015) est la famille Keccak, construction éponge, conçue par Bertoni, Daemen, Peeters et Van Assche, sélectionnée à l'issue d'une compétition publique du NIST. SHA-3 n'est pas un remplaçant de SHA-2 (SHA-2 est encore sûr) ; c'est une alternative défensive avec une structure interne fondamentalement différente, de sorte qu'une cassure hypothétique future de SHA-2 ne toucherait pas nécessairement SHA-3. Pour de nouvelles applications en 2026, SHA-256 reste le bon défaut ; SHA-3 est de plus en plus utilisé dans Ethereum et les schémas post-quantiques. Cet outil supporte aujourd'hui SHA-2 (SHA-1 / 256 / 384 / 512) ; SHA-3 est sur la liste des futures fonctionnalités.

Qu'est-ce que HMAC et quand en ai-je besoin ?

HMAC (Hash-based Message Authentication Code, RFC 2104, 1997) est une construction de hachage à clé qui prouve qu'un message a été créé par quelqu'un qui connaît un secret partagé. Vous en avez besoin chaque fois que vous vérifiez qu'une requête vient de la bonne partie, vérification de signatures de webhooks GitHub (le secret est la clé de signature du webhook), signatures de webhooks Stripe, signatures de requêtes API AWS (Signature v4 est HMAC-SHA-256), ou signatures JWT (HS256 = HMAC-SHA-256). HMAC reste sûr même quand le hash sous-jacent a une résistance aux collisions faible, raison pour laquelle HMAC-MD5 est encore considéré sûr, mais HMAC-SHA-256 est le défaut moderne pour le code récent.

Mon fichier est-il téléversé quand je le hashe ?

Non. Le fichier est lu directement dans votre navigateur via la File API et hashé localement, via la Web Crypto API pour les algorithmes de la famille SHA, via une petite implémentation JavaScript pour MD5. Rien ne traverse le réseau, vérifiez dans l'onglet Network des DevTools pendant le calcul, ou mettez la page hors ligne après son chargement. Sûr pour hasher des documents internes, des pièces d'identité numérisées, des captures d'interfaces en cours ou tout fichier que vous ne voudriez pas voir copié sur le disque dur d'un inconnu.

Outils associés