Résumé

  • Le RFC 1321 d’avril 1992 décrivit MD5 et inclut un programme C de référence, un pilote d’essai et sept sorties attendues. Les auteurs de logiciels disposaient ainsi d’un calcul commun à vérifier sur leurs propres machines.
  • Le RFC 6151 de 2011 révisa l’évaluation de sécurité : MD5 ne convenait plus aux applications demandant une résistance aux collisions, notamment les signatures numériques. Les sorties de test restaient des réponses exactes à la question du calcul.

Une norme que l’on pouvait faire tourner

Une empreinte MD5 ressemble aujourd’hui à une longue suite de caractères que le logiciel dépose sur la table sans explication. Le RFC 1321 remontait à la recette. Il fixait le bourrage des bits jusqu’à une longueur précise, l’ajout de la longueur initiale du message, l’état de quatre mots de 32 bits et le traitement par blocs de 512 bits. La moindre erreur d’ordre des octets ou de bourrage produisait un autre résultat. Pour échanger des empreintes, les programmeurs devaient d’abord s’accorder sur chaque petit geste du calcul.

Rivest leur donna de quoi vérifier ce geste. L’annexe A reproduisait quatre fichiers C : global.h, md5.h, md5c.c et mddriver.c. Le dernier servait à essayer des chaînes, des fichiers et l’entrée standard. Son option -x lançait une série d’essais prédéfinis. L’annexe A.5 imprimait les résultats attendus pour sept entrées, de la chaîne vide à des suites plus longues de lettres et de chiffres. Le célèbre petit abc devait produire 900150983cd24fb0d6963f7d28e17f72. Le lecteur pouvait donc écrire trois lettres, exécuter son programme et voir où il en était. Un sujet avec son corrigé, pour que deux ordinateurs indépendants se mettent d’accord.

Ces fichiers venaient de RSAREF, une boîte à outils cryptographiques destinée à Privacy-Enhanced Mail. Leur présence dans le RFC raccourcissait le trajet entre la page imprimée et l’exécutable. Un développeur pouvait s’appuyer sur la description, comparer son propre code à l’exemple et essayer les mêmes entrées. Un autre pouvait porter cet exemple vers sa machine et repérer vite une erreur de représentation. Le document qualifiait le code de portable et signalait même une optimisation possible pour certaines machines à octets de poids faible en premier. La règle était publique ; chacun pouvait la mettre à l’épreuve dans son atelier.

La décision de publier autant de détails avait aussi une histoire. MD5 prolongeait MD4. Selon le texte de 1992, MD4 avait peut-être été adopté plus vite que ne le justifiait l’examen critique alors disponible. MD5 ralentissait un peu la cadence pour prendre davantage de précautions. Rivest envisageait des signatures numériques : réduire un grand document à une empreinte, puis utiliser cette empreinte dans l’opération à clé privée. Le RFC était classé Informational et annonçait une mise dans le domaine public pour examen et éventuelle adoption comme norme. Il livrait à la fois une procédure exécutable et une confiance proposée dans sa solidité.

Le programme et les sept essais permettaient de répondre à une question nette : cette machine calcule-t-elle le MD5 décrit ? La résistance à une paire de messages délibérément construits pour partager la même empreinte exigeait, elle, l’examen des cryptanalystes. Une copie peut avoir toutes les réponses justes au contrôle de calcul et se retrouver devant une nouvelle question au contrôle de sécurité. C’est la différence entre reproduire fidèlement une opération et choisir un usage qui dépend d’une propriété de cette opération.

En mars 2011, le RFC 6151 réévalua cette seconde question. Après les attaques publiées contre MD5, il déclara l’algorithme inadapté lorsque la résistance aux collisions était nécessaire, comme pour les signatures numériques. Il examina séparément d’autres usages, dont HMAC-MD5 et les sommes de contrôle destinées à déceler des erreurs accidentelles, et déconseilla HMAC-MD5 dans les nouveaux protocoles. La valeur de abc continuait de sortir du programme ; le contrat de sécurité que l’on pouvait faire reposer sur cette sortie avait changé.

Le couple des deux RFC rend ce tournant particulièrement lisible. En 1992, une seule publication donnait les règles, une implémentation et des observations attendues. Les développeurs pouvaient partager une cible de calcul et traquer les écarts. En 2011, une autre publication mettait à jour l’appréciation du risque sans effacer ces observations. Un programme MD5 correct calculait toujours correctement MD5. Les signatures avaient besoin d’un autre choix. Le corrigé était resté au fond du livre ; c’était la matière de l’examen qui avait changé.