Encodeur RFC 1751 S/KEY

La RFC 1751 définit une convention fixe pour transformer des clés cryptographiques binaires en courtes chaînes de mots anglais, afin que l'on puisse lire, mémoriser et saisir un matériel de 64 et 128 bits sans la fatigue de l'hexadécimal. Le même dictionnaire alimente les mots de passe à usage unique classiques de S/KEY : chaque bloc de huit octets devient six mots tirés d'une liste de 2048 jetons d'une à quatre lettres, avec deux bits réservés à la parité pour détecter les erreurs de transcription au décodage. Cette capacité encode une clé hexadécimale sous cette forme verbale et décode les mots en hex majuscule, en vérifiant les bits de parité sur chaque groupe de six mots.

Comment la RFC 1751 empaquette 64 bits en six mots anglais

Le dictionnaire de la RFC 1751 contient exactement deux mille quarante-huit mots anglais d'une à quatre lettres, de sorte que chaque mot indexe onze bits. Six mots fournissent soixante-six bits : soixante-quatre bits de matériel de clé plus un champ de parité de deux bits.

L'encodage parcourt chaque moitié de huit octets de votre clé comme un flux de bits, additionne des tranches consécutives de deux bits sur les soixante-quatre bits de données pour former un nibble de parité, ajoute les deux bits bas de parité, puis découpe le résultat de soixante-six bits en six indices de onze bits. Ces indices sélectionnent des mots de la liste fixe en majuscules, joints par des espaces.

Une clé pure de soixante-quatre bits devient donc exactement six mots ; une de cent vingt-huit bits est formée de deux moitiés indépendantes et devient douze mots. Le décodage inverse la carte : chaque mot doit figurer dans le dictionnaire, six mots reconstruisent neuf octets d'empaquetage, les huit premiers forment la moitié candidate de la clé, et les deux bits de parité stockés sont comparés à une somme de parité fraîche.

Un écart signifie un mot mal saisi ou un bit inversé et est rejeté avec un message clair d'échec de parité, non avec une clé silencieusement fausse. Le dictionnaire ne change jamais entre implémentations ; cette stabilité explique pourquoi les OTP S/KEY, les impressions de clé de l'ère SNMP et les outils modernes de récupération peuvent interopérer lorsqu'ils revendiquent tous la RFC 1751.

Cette page n'implémente que cette liste classique de mots — pas les mnémoniques BIP-39, ni le diceware EFF, ni des générateurs arbitraires de phrases — afin que l'intention de recherche reste ancrée à l'encodage de clés lisibles avec parité.

Où les clés en mots de style S/KEY restent utiles

Les opérateurs qui impriment encore ou dictent un matériel de soixante-quatre bits profitent bien davantage de six mots courts que de seize chiffres hex, surtout au téléphone ou à la radio. Les systèmes S/KEY et OTP qui émettent déjà des phrases RFC 1751 ont besoin d'un décodeur strict qui rejette les échecs de parité au lieu d'accepter une clé voisine qui authentifierait le mauvais principal.

Les laboratoires de formation à la sécurité enseignent l'hygiène de transcription en montrant comment un seul mot erroné inverse le bit de parité et interrompt le décodage. Les notes de réponse à incident stockent parfois le matériel de récupération hors ligne sous forme de groupes de mots lisibles, afin qu'un intervenant sans éditeur hex puisse encore ressaisir une clé plus tard.

Les auteurs de documentation qui se positionnent sur RFC 1751 ou les mots S/KEY veulent une page dédiée avec un outil en direct plutôt qu'une page générique Base32 ou BIP-39, car le dictionnaire, la règle de parité et les longueurs de clé diffèrent. Une validation en échec ne consomme pas le solde.

Limitez les requêtes aux tailles de clé documentées, figez l'hex majuscule et les chaînes de mots dans les tests, et vous obtenez des transformations reproductibles pour les flux de récupération, les outils OTP et les workers en périphérie sans monter une boîte à outils cryptographiques complète de votre côté.