02. MD5 : limites et migration raisonnée

Comprendre le mécanisme

MD5 ne convient plus aux usages exigeant une résistance aux collisions, notamment les signatures numériques. Une collision consiste à produire deux entrées ayant la même empreinte ; cela ne signifie pas que tout mot de passe ou tout fichier arbitraire devient immédiatement récupérable depuis son hash. La faiblesse de MD5 ne doit pas non plus être confondue mécaniquement avec toutes les propriétés de HMAC-MD5. Les nouveaux protocoles doivent choisir des alternatives adaptées.

Raisonner et vérifier

Inventoriez l’usage avant migration. Un checksum de compatibilité historique, une signature de document et un stockage de mot de passe ne demandent pas le même remplacement. Pour un mot de passe, passer de MD5 à un hash rapide moderne conserve un défaut de conception : les essais hors ligne restent peu coûteux. Évitez les collisions prêtes à l’emploi sur des systèmes tiers ; démontrez le raisonnement sur des fixtures et une architecture de laboratoire.

Collision exploitable

MD5 est impropre aux nouvelles signatures exigeant la résistance aux collisions. Les collisions connues excluent ce choix pour cet usage. Une signature qui s’appuie sur une empreinte à collisions faibles peut ne plus distinguer des documents choisis par un attaquant. Pour une nouvelle conception, sélectionnez une construction actuelle adaptée à la propriété recherchée.

Préimage distincte

Une collision n’inverse pas tout hash arbitraire. Les objectifs et difficultés sont distincts. Ne présentez pas une paire de fichiers en collision comme une méthode de récupération de tout original. Le modèle d’attaque et le contrôle permis sur les messages déterminent ce que l’expérience démontre réellement.

Construction HMAC

HMAC-MD5 demande une analyse distincte du hash nu. La construction HMAC possède d’autres propriétés à analyser. Les attaques contre un hash nu et celles contre un MAC à clé ne se transfèrent pas mécaniquement. Analysez la construction et les contraintes héritées, tout en évitant HMAC-MD5 dans un nouveau protocole.

Nouveau protocole

Un nouveau protocole doit préférer des alternatives adaptées. La compatibilité héritée ne justifie pas ce choix nouveau. Privilégiez des API et profils maintenus, avec séparation des clés et formats définis. Remplacer seulement le nom MD5 sans revoir le protocole peut laisser le défaut d’authentification ou de rejeu intact.

Mots de passe

Un mot de passe ne se migre pas simplement vers un hash rapide. La fonction de mot de passe doit gérer un coût approprié. Remplacer MD5 par SHA-256 direct maintient un coût d’essai faible. Une migration doit viser un hash adaptatif de mot de passe, avec politique de vérification et remise à niveau après succès.

Inventaire des usages

La migration dépend du rôle du hash. Leurs menaces et propriétés attendues diffèrent. Une empreinte peut servir de clé de cache, de compatibilité ou de preuve cryptographique. Classez ces usages avant de changer le format : leurs risques et leurs consommateurs ne sont pas interchangeables.

Consommateurs hérités

L’inventaire doit inclure les consommateurs hérités. D’autres composants peuvent encore interpréter l’ancien format. Recherchez exports, API et scripts qui interprètent encore la sortie historique. Versionnez le contrat de transition et vérifiez que l’ancien chemin ne reste pas une possibilité de contournement indéfinie.

Compatibilité annoncée

Une empreinte MD5 de compatibilité ne doit pas être présentée comme preuve forte d’auteur. La provenance et les propriétés cryptographiques manquent. Un ancien checksum peut rester nécessaire pour échanger avec un outil. Marquez clairement sa finalité et fournissez une preuve moderne séparée si une authenticité forte du document est exigée.

Retrait organisé

Les anciens chemins doivent avoir un plan de retrait. Une compatibilité illimitée conserve le risque. Définissez date, propriétaire et métrique de trafic de l’ancien format. Un double support permanent augmente les chemins à maintenir et laisse parfois les clients sélectionner la protection la plus faible.

Laboratoire borné

Les démonstrations doivent rester dans un laboratoire. Le périmètre d’essai doit être maîtrisé. Utilisez des données factices et des fichiers de démonstration connus. Conservez versions et résultats, puis expliquez la propriété observée sans extrapoler vers des systèmes ou documents tiers.

Atelier guidé : lire, expliquer et vérifier le code

<?php
declare(strict_types=1);
echo strlen(md5('lab-document'));

Le programme affiche la longueur de la représentation hexadécimale MD5, soit 32 caractères. Cette mesure ne dit rien sur sa résistance aux collisions. Distinguez la propriété vérifiée par le code de celle requise par un stockage de mot de passe ou une signature de document.

La longueur seule ne donne pas cette garantie. Le type string ne prouve pas la propriété cryptographique. La taille du document ne justifie pas cette conclusion. La représentation de la sortie n’annule pas les faiblesses de collision.

Travail pratique : Classez trois usages hérités : checksum public, vérification de mot de passe et signature d’un document. Proposez un plan pour chacun.

Critères de correction : Documentez la provenance du checksum ; utilisez une fonction de mot de passe adaptée avec migration contrôlée ; remplacez la chaîne de signature et ses dépendances selon les contraintes du système. Gardez des tests de compatibilité limités et un calendrier de retrait.