Convertir MD5 en SHA-256 ? Pourquoi c’est impossible (et quoi faire)

Beaucoup de pages promettent de le faire, et certaines ressemblent à de vrais outils. L’opération qu’elles annoncent n’existe pas. La raison mérite deux minutes, parce qu’elle change ce que vous devez faire ensuite.

La réponse courte : convertir MD5 en SHA-256 (ou SHA-256 en MD5) est impossible

Vous ne pouvez pas convertir un hachage MD5 en SHA-256. Une empreinte MD5, ce sont 128 bits de sortie qui ne contiennent pas l’entrée qui les a produits. SHA-256 a besoin de cette entrée pour calculer quoi que ce soit. Sans les données d’origine, l’étape intermédiaire manque définitivement, et aucun outil ni aucune bibliothèque ne la remplace.

Voici la même entrée passée dans trois algorithmes :

Algorithme	Empreinte de `hello`	Caractères hex	Bits
MD5	`5d41402abc4b2a76b9719d911017c592`	32	128
SHA-1	`aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d`	40	160
SHA-256	`2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824`	64	256

Regardez ces trois empreintes comme de simples chaînes de caractères. Elles ne partagent ni préfixe ni sous-chaîne, et aucune opération arithmétique ne mène de l’une à l’autre. La seule chose qui les relie est le mot hello, et aucune des trois ne le transporte. Calculez-les vous-même avec le générateur de hash MD5 et le générateur de hash SHA-256 si vous voulez les voir changer indépendamment à mesure que vous tapez.

Le sens n’y change rien non plus. Aller de SHA-256 vers MD5 échoue exactement pour la même raison : les deux fonctions détruisent l’information à dessein, donc aucune des deux empreintes ne peut être remontée jusqu’à l’entrée dont l’autre aurait besoin.

Personne ne tape cette recherche par curiosité théorique sur le hachage. Vous aviez quelque chose de précis à faire, et c’est presque toujours l’une de ces quatre tâches, chacune avec sa propre réponse :

Vérifier un téléchargement ou comparer des sommes de contrôle
Migrer une base de mots de passe hors de MD5
Retrouver l’entrée d’origine derrière une empreinte
Obtenir les mêmes données hachées avec un autre algorithme

Chacune est traitée plus bas. Avant ça, les pages qui promettent la conversion : reconnaître leur procédé vous évite de faire confiance à ce qu’elles affichent.

Ce que fait réellement une page « convertisseur MD5 vers SHA-256 »

Il n’y a que trois possibilités, et aucune n’est une conversion.

Elle vous demande le texte d’origine. Vous collez une chaîne, la page produit les deux empreintes, et l’argumentaire commercial appelle ça une conversion. C’est un générateur de hachage avec une étiquette trompeuse. Rien n’a été converti ; l’entrée a été hachée deux fois.

Elle cherche l’empreinte dans une table. La page conserve une table de paires entrée-empreinte moissonnées dans des listes de mots et des fuites d’identifiants. Collez un MD5 dont l’entrée figure dans cette table, la page retrouve l’entrée, la hache avec SHA-256 et vous montre le résultat. Ça marche pour password, 123456 et une longue traîne d’autres chaînes courtes. Ça échoue silencieusement sur tout le reste, ce qui explique pourquoi ces pages renvoient souvent un résultat vide sans la moindre explication.

Elle ne fait rien. Un nombre étonnant d’entre elles se contentent de réafficher votre saisie, ou renvoient le SHA-256 de la chaîne hexadécimale que vous avez collée en laissant croire que c’est le SHA-256 de vos données d’origine. Ces deux valeurs sont différentes, et la section sur le double hachage, plus bas, montre à quel point.

Le test est rapide. Donnez à la page une chaîne hexadécimale de 32 caractères et rien d’autre, puis demandez-vous s’il lui est seulement possible de connaître l’entrée. Si elle renvoie malgré tout un résultat de 64 caractères en appelant ça une conversion, c’est qu’elle interroge une table de correspondance ou qu’elle vous ment. Un convertisseur de hachage qui ne demande jamais vos données d’origine n’a aucun moyen d’avoir raison, sinon par coïncidence.

L’expression survit parce qu’elle ressemble à une opération voisine qui, elle, fonctionne bel et bien. La confusion vient de là.

Hachage, encodage et chiffrement : seuls deux des trois sont réversibles

Les développeurs croisent ces trois notions dans la même semaine et les rangent dans le même tiroir mental. Elles se comportent pourtant de manière totalement différente :

Opération	Exemple	Réversible ?	Ce qu’il vous faut
Encodage	Base64, hexadécimal, encodage d’URL	Oui, toujours	Rien du tout
Chiffrement	AES, RSA	Oui	La clé
Hachage	MD5, SHA-1, SHA-256	Jamais	Rien n’y fait

C’est Base64 qui installe la mauvaise intuition. N’importe qui peut décoder une chaîne Base64 pour retrouver ses octets, sans clé et sans autorisation, et convertir du Base64 en hexadécimal est une opération légitime et quotidienne. Les deux ne sont que des orthographes différentes des mêmes octets. Quand on a vu ça fonctionner, « MD5 vers SHA-256 » sonne comme une réécriture du même genre.

Ce n’en est pas une. L’encodage préserve chaque bit de l’entrée, le chiffrement le préserve derrière une clé, et le hachage en jette presque tout. Une empreinte MD5 fait 16 octets, que vous lui ayez donné un mot de passe ou une image disque de 40 Go. Ces 40 Go ne sont pas rangés quelque part de façon astucieuse : ils ont disparu. La FAQ de l’outil MD5 détaille la comparaison avec le chiffrement si vous la voulez, mais la version en une ligne suffit ici : il n’y a pas de clé, donc il n’y a rien à déchiffrer.

« MD5 est cassé » ne veut pas dire « MD5 est réversible »

C’est le point que même les articles honnêtes ratent, et il compte parce qu’on passe directement de « MD5 a été cassé il y a des années » à « donc quelqu’un doit bien savoir l’inverser aujourd’hui ».

Deux attaques différentes sont en jeu :

Une attaque par collision trouve deux entrées différentes qui produisent la même empreinte. L’attaquant choisit les deux entrées et se moque de ce qu’elles contiennent.
Une attaque par préimage part d’une empreinte et retrouve une entrée qui la produit. C’est celle qui permettrait de convertir MD5 en SHA-256, puisqu’elle vous rendrait quelque chose à donner à SHA-256.

La résistance aux collisions de MD5 est tombée en 2004, et une collision se construit aujourd’hui en quelques secondes sur du matériel ordinaire. C’est pour cette raison que MD5 ne convient ni aux signatures, ni aux certificats, ni à quoi que ce soit qu’un adversaire peut influencer.

La résistance aux préimages de MD5, elle, n’est pas tombée. La meilleure attaque par préimage connue reste théorique, avec une complexité de 2^123.4 (Sasaki et Aoki, 2009). C’est à peine plus rapide que la force brute, et hors d’atteinte en pratique. Personne n’inverse des empreintes MD5 arbitraires, ni en 2004 ni aujourd’hui.

Les deux faits cohabitent sans se contredire : MD5 est cassé, et MD5 n’est toujours pas réversible. Sa cassure ne change donc rien à ce qui précède. Si vous hésitez entre les deux algorithmes pour un nouveau système plutôt que d’essayer de passer de l’un à l’autre, la comparaison MD5 vs SHA-256 couvre cette décision.

Quatre tâches derrière la question, et la réponse de chacune

Ce que vous faites	Ce qu’il faut faire à la place
Vérifier un téléchargement ou comparer des sommes de contrôle	Recalculer depuis le fichier avec l’algorithme voulu
Migrer des mots de passe hachés en MD5	Les envelopper dans bcrypt et migrer chaque compte à la connexion
Retrouver l’entrée d’origine	C’est du cassage, pas de la conversion, et tout dépend de l’entropie
Rehacher les mêmes données avec un autre algorithme	Repartir des octets sources

Tâche 1 : vous comparez des sommes de contrôle ou vérifiez un téléchargement

Recalculez, ne convertissez pas. Le fichier est là, sur votre disque, ce qui veut dire que vous détenez la seule chose que l’empreinte a perdue. Lancez dessus l’algorithme dont vous avez besoin :

# GNU coreutils
md5sum    ubuntu-24.04-desktop-amd64.iso
sha256sum ubuntu-24.04-desktop-amd64.iso

# macOS
md5           ubuntu-24.04-desktop-amd64.iso
shasum -a 256 ubuntu-24.04-desktop-amd64.iso

Le cas gênant, c’est l’éditeur qui ne publie qu’un MD5 alors que votre politique de sécurité exige du SHA-256. Convertir le MD5 publié ne prouverait rien, même si c’était possible, parce qu’une empreinte que vous avez dérivée d’une autre empreinte n’est pas une déclaration de l’éditeur au sujet du fichier. Ce qu’il vous faut, c’est un SHA-256 signé par l’éditeur. S’il n’en propose pas, calculer votre propre SHA-256 avec le générateur de hash SHA-256 vous donne quand même une empreinte stable pour un usage interne : vous pouvez l’épingler et la comparer d’un miroir à l’autre pour repérer un changement plus tard. Elle ne peut simplement pas remplacer l’attestation de l’éditeur.

Tâche 2 : vous migrez une base de mots de passe hors de MD5

C’est la tâche où les enjeux sont les plus lourds, et elle a une solution éprouvée : envelopper les anciens hachages, puis migrer chaque compte de façon transparente à la connexion. Vous passez chaque hachage MD5 stocké dans bcrypt en un seul traitement par lot, et à partir de là le chemin de connexion commence par hacher en MD5 le mot de passe soumis, puis compare le résultat à l’enregistrement bcrypt.

Un avertissement d’abord, parce que beaucoup de conseils anciens prennent le problème à l’envers. Envelopper MD5 dans SHA-256 ne rend pas le stockage des mots de passe sûr. SHA-256 est un hachage rapide, la même catégorie de problème que MD5, et les GPU les avalent tous les deux à des cadences énormes. Les conseils qui vous orientent vers la fonction SHA2() intégrée d’une base de données répondent au mauvais problème. La cible, c’est un hachage délibérément lent : bcrypt, scrypt ou Argon2. Stockez bcrypt(md5(password)), jamais sha256(md5(password)). La comparaison bcrypt vs Argon2 vs scrypt explique comment choisir parmi les trois, et le générateur bcrypt vous laisse tester des facteurs de coût avant de vous engager.

Ce qui casse les migrations est ailleurs. « Le MD5 du mot de passe » est ambigu, et les deux lectures produisent des résultats différents :

const { createHash } = require('node:crypto');

const md5Hex = createHash('md5').update('hello').digest('hex');
const md5Raw = createHash('md5').update('hello').digest();   // the same value as 16 bytes

createHash('sha256').update(md5Hex).digest('hex');
// 4914e23374bb211e3dca0df7636fefffc7fedd94f1340ae81c7d6c07b7113e9b

createHash('sha256').update(md5Raw).digest('hex');
// 88e20f0abb88153e3f0a9683668ccb5b84ed771817dc448a2b73254ed02c8d8c

createHash('sha256').update('hello').digest('hex');
// 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Trois résultats, tous corrects, tous différents. Hachez la chaîne hexadécimale de 32 caractères et vous obtenez une valeur ; hachez les 16 octets bruts qu’elle représente et vous en obtenez une autre ; hachez le mot de passe d’origine et vous en obtenez une troisième. Choisissez une convention, écrivez-la noir sur blanc, et appliquez la même dans le script de migration et dans le chemin de connexion. Se tromper là-dessus verrouille tous les utilisateurs d’un coup, et le symptôme ressemble à un bug de bcrypt plutôt qu’à une décision d’encodage.

Pour une enveloppe bcrypt, l’hexadécimal est la convention la plus sûre. Les octets bruts d’une empreinte peuvent contenir un octet nul, et plusieurs implémentations de bcrypt traitent leur entrée comme une chaîne C et s’arrêtent de lire à cet endroit. L’hexadécimal évite complètement le problème, et avec 32 caractères il reste largement sous la limite de longueur d’entrée de bcrypt. Normalisez aussi la casse, puisque 5D41402A... et 5d41402a... sont deux chaînes différentes pour bcrypt, même s’il s’agit de la même empreinte.

const bcrypt = require('bcrypt');
const { createHash } = require('node:crypto');

const legacyDigest = (password) =>
  createHash('md5').update(password, 'utf8').digest('hex');   // lowercase hex

// Batch job, run once: wrap each stored MD5, then drop the old column.
async function wrapRow(row) {
  return bcrypt.hash(row.md5_hash.toLowerCase(), 12);
}

// Login path
async function verify(password, row) {
  if (row.scheme === 'bcrypt') {
    return bcrypt.compare(password, row.hash);
  }
  const ok = await bcrypt.compare(legacyDigest(password), row.hash);
  if (ok) {
    const upgraded = await bcrypt.hash(password, 12);
    await saveCredential(row.id, { scheme: 'bcrypt', hash: upgraded });  // your DB write
  }
  return ok;
}

Les comptes basculent vers du bcrypt simple au fur et à mesure que leurs propriétaires se connectent. Fixez une échéance pour les retardataires et forcez une réinitialisation passé ce délai.

Tâche 3 : vous essayez de retrouver l’entrée d’origine

Dites-le franchement, au moins à vous-même, parce que ça change les outils et les attentes. Retrouver une entrée à partir d’une empreinte, c’est du cassage, pas de la conversion, et la réussite ne dépend pas du tout de l’algorithme qui a produit l’empreinte. Elle dépend de l’entrée.

Les chaînes courtes que des humains ont choisies tombent vite. Les mots du dictionnaire, les prénoms suivis d’un chiffre et tout ce qui a déjà figuré dans un corpus de fuite tombent devant une simple recherche en table ou une courte attaque par force brute. Les chaînes longues et aléatoires, elles, ne tombent pas du tout, et l’écart entre les deux cas ne se comble pas en achetant plus de matériel.

Sur les tables arc-en-ciel, la formulation courante est trop large. Une table arc-en-ciel ne retrouve une entrée que si cette entrée a été hachée sans sel et qu’elle est déjà présente dans la table. Les deux conditions sont nécessaires. Ajoutez un sel par utilisateur et la table précalculée ne vaut plus rien, parce que l’attaquant aurait besoin d’une table distincte par sel. Donnez au hachage un jeton aléatoire de 128 bits et aucune table sur terre ne le contient. Le guide de l’entropie des mots de passe met des chiffres sur l’endroit où passe cette frontière.

Si l’entrée était un mot de passe qui vous appartient et que vous n’arrivez pas à le reproduire, traitez ça comme une réinitialisation, pas comme une récupération. S’il appartient à quelqu’un d’autre, la formulation honnête est celle donnée plus haut.

Tâche 4 : il vous faut les mêmes données hachées avec un autre algorithme (« convertisseur md5 vers sha1 »)

Même forme que la tâche 1, en plus général. La paire d’algorithmes demandée n’a aucune importance, parce que la réponse est toujours de repartir des octets sources et de les hacher à nouveau :

sha1sum   payload.bin
sha256sum payload.bin

Tous les « convertisseurs md5 vers sha1 » que vous trouverez sont des rehacheurs ou des tables de correspondance, pour les raisons vues plus haut. Si les données d’origine ne sont pas disponibles, la tâche n’a pas de solution, et ce n’est pas une limite des outils existants. Choisissez l’algorithme cible avec la comparaison de la famille SHA ; le générateur de hash SHA-1 est là pour les systèmes historiques qui l’exigent encore, même si plus rien de neuf ne devrait le faire.

Le seul cas où la recherche en table d’un convertisseur de hachage marche vraiment

Certaines catégories de données sont collectées de façon centralisée et indexées d’un coup par toutes les empreintes courantes. Les échantillons de malwares en sont l’exemple type. Des services comme VirusTotal stockent l’échantillon lui-même : ils ont donc calculé ses MD5, SHA-1 et SHA-256 à partir des mêmes octets et classé les trois sous un même enregistrement. Cherchez-y le MD5 d’un échantillon et vous récupérez son SHA-256.

C’est une jointure de base de données, pas une conversion. Ça marche parce que quelqu’un disposait du fichier d’origine et l’a haché avec tous les algorithmes, exactement l’étape de recalcul décrite plus haut, simplement faite à l’avance par un tiers. Les conditions sont strictes : l’objet doit déjà figurer dans l’index, et vous devez faire confiance à celui qui l’a construit. Les workflows de renseignement sur les menaces s’appuient là-dessus tous les jours. Ça ne dit rien des empreintes MD5 arbitraires, et ça ne vous aidera jamais avec l’empreinte de vos propres données.

C’est le mécanisme qu’utilisent les pages de conversion douteuses. La différence, c’est qu’un dépôt de malwares vous dit qu’il s’agit d’une recherche en table et vous montre l’enregistrement.

Essayez vous-même

Deux empreintes de la même entrée changent en même temps sans avoir le moindre rapport entre elles. C’est plus parlant à l’écran que sur le papier :

$ printf 'hello' | md5sum
5d41402abc4b2a76b9719d911017c592  -
$ printf 'hello' | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -

Changez un seul caractère et les deux sorties changent complètement, de manières qui n’ont rien à voir entre elles. Collez le même texte dans le générateur de hash MD5 et le générateur de hash SHA-256 côte à côte pour le voir en direct, ou passez au générateur HMAC si ce qu’il vous faut est une empreinte avec clé pour signer une requête d’API. Les trois tournent entièrement dans votre navigateur.

FAQ

Peut-on convertir MD5 en SHA-256 ?

Non. Une empreinte MD5 ne contient pas l’entrée d’origine, et SHA-256 a besoin de cette entrée pour produire quoi que ce soit. Toute page qui prétend convertir se contente de rehacher un texte que vous fournissez, ou de chercher la valeur dans une base de paires précalculées.

Pourquoi tant de sites proposent-ils un « convertisseur MD5 vers SHA-256 » ?

Ils se positionnent sur une requête que les gens tapent. Une fois arrivé sur la page, soit elle vous demande votre texte d’origine, ce qui en fait un rehachage et non une conversion, soit elle ne renvoie rien d’utile. La formule tient parce que l’idée fausse qui la porte est répandue.

Est-il possible de reconvertir SHA-256 en MD5 ?

Non, et le sens n’y change rien. Les deux sont des fonctions à sens unique, donc aucune des deux empreintes ne peut être transformée en l’autre sans l’entrée d’origine. Un outil qui propose le trajet inverse applique la même astuce de recherche en table ou de rehachage.

MD5 est cassé : cela ne veut-il pas dire qu’on peut l’inverser ?

Non. La résistance aux collisions de MD5 est tombée en 2004, ce qui signifie que deux entrées peuvent être forcées à partager une empreinte. Inverser une empreinte est une attaque par préimage, et la meilleure connue coûte encore 2^123.4 opérations. Cassé pour les signatures, toujours pas inversible.

Comment migrer une base de mots de passe hachés en MD5 vers quelque chose de plus sûr ?

Sous MySQL, UPDATE users SET password = SHA2(password, 256) est faux : cela hache l’empreinte MD5 stockée, pas le mot de passe. Stockez bcrypt(md5(password)), vérifiez à travers la même enveloppe et migrez chaque enregistrement à la prochaine connexion réussie. Envelopper MD5 dans SHA-256 n’aide pas, parce que les deux sont des hachages rapides et qu’un GPU traite l’un comme l’autre à la même cadence brutale.

Pourquoi le double hachage m’a-t-il donné un résultat différent de celui attendu ?

Hacher la chaîne hexadécimale MD5 et hacher ses 16 octets bruts produisent des sorties SHA-256 différentes. Les deux sont valides ; ce sont simplement deux entrées différentes. Choisissez une convention et appliquez-la à l’identique dans le script de migration et dans le chemin de connexion.

Une table arc-en-ciel peut-elle retrouver l’entrée derrière une empreinte MD5 ?

Uniquement si l’entrée était non salée et qu’elle figure déjà dans la table, ce qui en pratique veut dire des chaînes courtes ou courantes. Les entrées longues et aléatoires ne sont pas récupérables par ce moyen, et ajouter un sel par utilisateur met complètement en échec les tables précalculées.

Existe-t-il un convertisseur MD5 en SHA-1 ?

Non. Tout « convertisseur MD5 en SHA-1 » est un rehacheur ou une table de correspondance, parce que le sens unique bloque le trajet MD5 vers SHA-1 exactement comme il bloque MD5 vers SHA-256. Si vous avez encore l’entrée d’origine, recalculez l’empreinte avec le générateur SHA-1 ; sans elle, rien n’y parvient.

Convertir MD5 en SHA-256 ? Pourquoi c'est impossible (et quoi faire)