Résumé

  • RFC 1319 décrit MD2 comme une fonction qui transforme un message de longueur arbitraire en une empreinte ou un condensat de 128 bits.
  • Le RFC le destine aux applications de signature numérique, donne des estimations contemporaines pour une collision ou une cible de condensat prescrite, et indique que l’algorithme exigeait encore une analyse supplémentaire.
  • Une égalité de condensat est un résultat de calcul sur des octets et un algorithme nommés. Elle n’est pas à elle seule une signature, une identité, une preuve de contrôle de clé, un journal de transport, une réception, un horodatage ou une décision d’autorisation.

Un petit nombre ne résumait pas un grand événement

Le problème résolu par un condensat est élégant : comparer ou manipuler la représentation fixe d’un message dont la longueur n’est pas fixe. RFC 1319 dit que MD2 accepte un message de longueur arbitraire et produit un résultat de 128 bits. Cette concision est utile. Elle ne fait pas du résultat une biographie des octets.

Pour qu’un condensat signifie déjà « ces octets ont donné cette valeur », il faut conserver au minimum les octets ou une représentation exactement nommée, l’algorithme, le composant qui a calculé, le résultat et le contexte de lecture. L’affichage d’un même texte ne garantit pas la même entrée : codage de caractères, fins de ligne, décodage de transfert, encapsulation et normalisation peuvent modifier la séquence présentée à l’algorithme. Une valeur conservée sans son entrée reste une assertion sur une séquence absente. Elle peut servir à comparer une séquence candidate plus tard ; elle ne reconstruit ni l’entrée ni son parcours.

Le mot « empreinte » est ici une métaphore de calcul. Il ne transforme pas le message en personne. RFC 1319 ne définit ni registre d’identités, ni certificat, ni titulaire de clé, ni expéditeur, ni destinataire. La familiarité du mot ne peut pas ajouter ces acteurs au modèle.

MD2 désignait une transformation d’octets

Le RFC décrit le traitement nécessaire pour produire la valeur : remplissage, somme de contrôle et tampon interne de 48 octets avant l’extraction de 16 octets de résultat. Ces détails ne sont pas seulement de l’implémentation. Ils rappellent qu’une empreinte appartient à une entrée déterminée et à une procédure déterminée.

Les exemples du document sont donc des vecteurs de contrôle. Une implémentation qui retrouve le même résultat pour l’entrée indiquée possède une évidence sur son calcul. Elle ne possède pas une preuve d’auteur, de diffusion réseau ou de réception. Un vecteur de test valide une fonction, pas l’histoire d’un message.

Cette limite apparaît aussi lorsqu’un système dit qu’il a « le même fichier ». Même nom, même rendu ou même contenu logique ne dit pas forcément que les mêmes octets ont été hachés. Il faut préciser si le calcul portait sur une enveloppe, une charge utile extraite, un contenu décodé ou une représentation normalisée. Sinon deux lecteurs peuvent croire comparer le même objet alors qu’ils comparent deux couches différentes.

La résistance attendue ne créait pas une identité

RFC 1319 explique l’objectif de rendre difficile la production de deux messages donnant le même condensat et difficile la production d’un message pour une valeur cible déjà choisie. Ses estimations de 1992 sont de l’ordre de 2^64 opérations pour le premier problème et de 2^128 pour le second. Le même RFC précise que MD2 était relativement nouveau et demandait une analyse supplémentaire.

Ces phrases répondent à une question étroite : quelle difficulté était attendue pour certaines substitutions de messages, sous l’algorithme décrit ? Elles ne répondent pas à « qui a produit le message ? », « qui a publié la valeur ? », « à quel moment les octets ont-ils circulé ? » ou « qui a accepté le résultat ? ». Une valeur peut être correctement calculée sur une copie obtenue par une source inconnue. Une valeur annoncée peut venir d’une page non authentifiée. Un candidat peut avoir été créé après l’enregistrement de la valeur. Aucune de ces histoires n’est encodée dans les 128 bits.

La résistance aux collisions et l’attribution traitent de problèmes différents. La première cherche à rendre certains remplacements difficiles. L’attribution exige un lien indépendant entre une assertion et une identité : registre, clé, politique ou procédure de vérification. MD2 ne définit pas d’opération à clé privée ; il ne peut donc démontrer la possession d’une telle clé. Il ne produit ni consentement, ni non-répudiation, ni droit d’agir.

Il serait tout aussi imprécis de lire les estimations du RFC comme un jugement intemporel ou universel. Elles appartiennent au texte de 1992 avec son avertissement explicite. L’article historique doit conserver l’attente et l’incertitude, plutôt que d’emprunter au RFC une conclusion sur un environnement actuel qu’il ne documente pas.

L’application de signature ajoutait ses propres faits

Dire que MD2 est destiné aux applications de signature numérique ne dit pas que MD2 signe. Dans une telle application, le condensat peut devenir l’entrée d’une autre opération, laquelle a son algorithme de signature, sa clé privée, sa signature produite, sa clé publique, sa vérification et sa règle d’association entre clé et identité revendiquée.

L’ordre protège l’enquête. D’abord, des octets définis sont soumis à MD2. Ensuite, un composant peut signer selon un schéma distinct. Ensuite, un vérificateur peut contrôler cette signature avec une clé publique. Ensuite encore, un annuaire ou une règle de confiance peut expliquer quel nom, quelle organisation ou quelle autorité cette clé représente. Enfin, une application décide si cette assertion suffit à autoriser une action. Une transmission et la réception par un tiers peuvent rester des événements entièrement séparés.

La confusion s’entend dans des phrases rapides : « le hachage a signé le document », « l’empreinte prouve l’expéditeur », « le digest atteste la réception ». Chacune commence avec un calcul puis emprunte une conclusion à un autre registre. Une signature peut ajouter une assertion liée à une clé ; elle ne remplace pas automatiquement l’identité de la clé. Une identité vérifiée ne remplace pas une réception. Une réception ne remplace pas une décision d’autorisation.

Une concordance devait rester une comparaison bornée

Supposons qu’un expéditeur conserve une copie et qu’une archive en conserve une autre. Si la même procédure MD2 appliquée aux deux entrées donne la même valeur, l’observation est utile : les calculs ont coïncidé sur ces entrées. Ce résultat ne prouve pas que l’archive a reçu sa copie de cet expéditeur. Elle a pu l’obtenir ailleurs ; l’expéditeur a pu la créer après coup ; les données capables de distinguer ces scénarios peuvent ne jamais avoir été collectées.

Le même raisonnement vaut pour une valeur imprimée à côté d’un téléchargement. Elle indique la valeur que devrait produire une copie candidate. Elle n’authentifie pas automatiquement la page qui l’a publiée. Un canal distinct, une signature ou un registre de confiance peut traiter cette question, mais le condensat demeure l’objet de comparaison.

La bonne conservation est donc plurielle : octets bruts ou représentation explicitement décrite, identifiant d’algorithme, valeur calculée, composant et instant de calcul ; puis signature et trace de vérification lorsqu’elles existent ; puis fondement de l’identité de clé, trace de transfert, réception et décision d’usage. Ces éléments peuvent se corroborer sans se confondre.

Le silence du RFC n’était pas une constatation négative

RFC 1319 ne nomme pas une implémentation active, un détenteur de clé, une politique de certificat, un service de temps, un chemin de réseau ou un destinataire. Cela ne prouve pas qu’aucun environnement n’a de telles données. Cela prouve seulement que la spécification de l’algorithme n’en est pas la source.

Une divergence de condensat doit recevoir la même retenue. Elle indique qu’une entrée candidate et une valeur attendue ne concordent pas sous le calcul spécifié. Elle ne démontre pas d’elle-même une malveillance, une panne de transport ou une faute de stockage. L’entrée a peut-être été décodée, normalisée, tronquée, emballée autrement ou mal étiquetée. Le condensat annonce l’échec d’une comparaison ; les traces de représentation et de chemin sont nécessaires pour expliquer la cause.

La force de RFC 1319 réside donc dans son étroitesse. Une empreinte rend une comparaison d’octets praticable. Elle perd cette précision lorsqu’on lui demande d’être simultanément signature, carte d’identité, accusé de réception et décision de politique.

Sources et limites de preuve

Cet article s’appuie sur RFC 1319, The MD2 Message-Digest Algorithm (avril 1992). Il établit l’entrée de longueur arbitraire, le résultat MD2 de 128 bits, les attentes de difficulté pour collision et cible prescrite, l’usage envisagé dans les applications de signature et l’avertissement sur l’analyse ultérieure. Il n’établit ni sûreté cryptographique actuelle, ni implémentation donnée, ni signature, ni identité de signataire, ni possession de clé, ni statut de certificat, ni temps fiable, ni origine, ni transport, ni stockage, ni réception, ni autorisation, ni non-répudiation, ni résultat applicatif.