Résumé

  • Publié en décembre 1994, le RFC 1751 proposait d’écrire une clé cryptographique de 128 bits sous forme de douze mots courts. Il appliquait deux fois la conversion de S/Key : six mots pour chacun des deux blocs de 64 bits.
  • La liste de 2 048 mots anglais devait rester identique d’un logiciel à l’autre. Le texte avertissait aussi qu’une phrase composée par l’utilisateur offrirait une clé plus prévisible qu’une valeur obscure d’abord choisie, puis simplement affichée en mots.

Le secret avait besoin d’une interface

Une station d’administration pouvait comparer des bits avec une fidélité parfaite. L’opérateur, lui, devait lire la clé, la recopier et la taper. Le RFC 1751 partait de cette scène peu glorieuse. Les protocoles de sécurité SNMPv2 fournissaient un contexte où des secrets de 128 bits servaient aux mécanismes d’authentification. La question de McDonald était plus étroite et plus quotidienne : comment faire passer cette matière entre l’écran et des doigts humains ?

S/Key avait déjà testé une méthode pour les mots de passe à usage unique. Sa représentation prenait une valeur de 64 bits et la découpait en six choix dans une liste fixe de 2 048 mots anglais, longs d’un à quatre caractères. Six choix offraient 66 bits de place, dont une petite marge pour la parité. Ces mots n’étaient pas des souvenirs choisis librement par leur propriétaire. Ils constituaient l’écriture lisible d’une valeur que le logiciel pouvait retrouver.

McDonald a emprunté cette mécanique plutôt que de créer une nouvelle roue. key2eng appliquait la conversion à la première moitié de la clé de 128 bits, puis à la seconde. eng2key faisait le trajet inverse. Le résultat comptait douze mots, en deux groupes de six. Un exemple du RFC commence par « RASH BUSH MILK LOOK BAD BRIM ». Voilà une formule peu susceptible de gagner un concours de poésie. Elle avait pourtant la qualité recherchée : les mots venaient de la clé, dans un ordre déterminé, et non d’une idée brillante surgie devant le clavier.

Le dictionnaire anglais unique constituait la décision politique miniature de cette histoire technique. McDonald expliquait que des listes différentes selon la langue casseraient l’échange entre implémentations : les mêmes bits donneraient des suites de mots différentes. La liste existante utilisait des caractères de la partie invariante d’ISO-646 et possédait déjà des utilisateurs. Le choix avantageait une carte commune sur la commodité d’un vocabulaire local. Pour un opérateur francophone, l’anglais faisait donc partie de la prise, au même titre que la longueur de la clé.

Le danger venait d’une inversion séduisante. Le logiciel pouvait transformer une clé suffisamment obscure en douze mots. Une personne pouvait aussi chercher douze mots qui forment une phrase facile à garder en tête et les entrer comme clé. Le RFC 1751 avertissait que ce second chemin rendait les possibilités plus prévisibles et ouvrait la porte à une recherche par phrases. La représentation aidait à transporter le secret; elle ne choisissait pas le secret à la place de l’opérateur.

Le document publiait le code de référence et la liste des mots. Cette abondance de détails avait un but pratique. Deux logiciels devaient convertir la même clé en la même suite, puis revenir exactement aux mêmes 128 bits. Sans dictionnaire immobile et sans conversion vérifiable dans les deux sens, les mots seraient plus faciles à prononcer mais moins fiables pour remettre une machine en service. La convivialité de l’interface dépendait de la discipline des implémentations.

Le RFC raconte ainsi un petit accord entre deux besoins réels. La machine travaille avec un nombre long et difficile à confondre; la personne manipule des morceaux courts qu’elle peut lire à haute voix ou saisir. Le passage entre les deux tient en une convention partagée. Le mécanisme est modeste, presque comique par ses combinaisons de mots, et sérieux au moment où une faute de copie fermerait l’accès à la machine.