Résumé

  • RFC 1969 réutilisait le dernier bloc chiffré d’un paquet comme entrée CBC du suivant : moins de matière d’initialisation à transporter, mais une dépendance qui franchissait la frontière PPP.
  • Le nonce initial de 64 bits était négocié en clair puis chiffré avec la clé DES partagée ; le numéro de séquence explicite de 16 bits signalait une rupture d’ordre, sans authentifier ni le contenu ni l’extrémité.
  • Si N-1 manque, N ne peut pas être déchiffré. Lorsque le chiffré de N est tout de même reçu, son dernier bloc permet de lire N+1 : la chaîne repart, les deux textes clairs perdus ne reviennent pas.

Une reprise qui commence par accepter la perte

La section « Recovery after Packet Loss » de RFC 1969 décrit une scène précise. Le paquet N-1 est perdu ou irrémédiablement endommagé. N et N+1 arrivent correctement. Pour lire N, le récepteur devrait posséder le dernier bloc chiffré de N-1 ; il ne l’a plus. Mais pour lire N+1, il lui suffit du dernier bloc de N, qui est visible dans le chiffré reçu même si le texte clair de N reste inaccessible.

La reprise n’efface donc pas l’incident. Deux textes clairs manquent : celui du paquet absent et celui du paquet devenu indéchiffrable. Le troisième redevient calculable. Il n’y a ici ni retransmission, ni correction des données, ni accusé de réception applicatif. La seule chose rétablie est la continuité de l’état cryptographique.

Cette nuance oblige aussi à conserver un paquet « inutile » pour son contenu. Jeter immédiatement N parce que son déchiffrement échoue supprimerait le bloc terminal qui permet de repartir. Dans un protocole à état, la valeur opérationnelle d’un paquet ne se réduit pas au texte qu’il livre.

Le choix d’une continuité au-delà de PPP

Publié en juin 1996 comme document Informational, RFC 1969 fournissait un protocole porteur DES pour le cadre ECP de PPP. Il appliquait DES avec une clé de 56 bits en mode CBC. Dans un paquet, chaque bloc clair est combiné au bloc chiffré précédent. Le choix distinctif consistait à faire du dernier chiffré d’un paquet le C[0] du paquet suivant.

La frontière du paquet restait visible pour PPP, mais cessait d’être une frontière d’état pour le chiffrement. La continuité compliquait la répétition de motifs identiques et évitait d’ajouter un nouveau vecteur d’initialisation à chaque datagramme. En échange, un paquet isolé ne contenait plus toutes les données nécessaires à son propre déchiffrement.

Ce compromis associe économie et fragilité locale. Le sender et le receiver doivent partager l’ordre exact du flux chiffré. Le numéro de séquence devient nécessaire parce que l’état n’est plus naturellement borné par le paquet. L’histoire générale de la négociation ECP appartient à RFC 1968 ; ici, ECP est déjà Opened et l’analyse commence sur le chemin des données.

Le nonce visible ne remplace pas le secret

L’option DESE contient un Type, une Length et un Initial Nonce de huit octets. Le récepteur propose la valeur que son pair utilisera pour le premier paquet envoyé dans sa direction. RFC 1969 recommande de la changer à chaque négociation ECP et suggère une construction temporelle, afin de réduire le risque de rejeu.

Ce nonce circule en clair. Il ne constitue pas la clé. Pour le premier paquet, la valeur initiale est E[k](nonce), calculée avec le secret DES partagé. Le récepteur peut reproduire ce calcul parce qu’il connaît le nonce qu’il a envoyé et la même clé. Pour les paquets suivants, le dernier chiffré prend la relève.

La spécification laisse hors champ l’obtention du secret. Une configuration manuelle est dite habituelle ; l’authentification PPP ou l’Endpoint Identifier de Multilink peuvent contribuer à choisir un secret. Aucun de ces indices ne transforme le nonce en preuve d’identité. Une trace réseau prouve qu’une valeur a été offerte. Un déchiffrement réussi prouve qu’un état et une clé compatibles existaient quelque part. Ni l’un ni l’autre n’est une attestation de l’organisation ou de l’utilisateur supposé.

Seize bits pour voir une discontinuité

Chaque paquet DESE porte un Sequence Number de 16 bits, à partir de zéro après l’ouverture d’ECP. Une rupture entre deux valeurs consécutives alerte le récepteur : le bloc terminal conservé ne correspond peut-être plus au prédécesseur du paquet présent.

Le champ ne vérifie pourtant aucun octet du chiffré. RFC 1969 ne lui associe pas de code d’authentification. Il ne révèle pas si le paquet a été modifié, rejoué, réordonné ou supprimé localement, ni qui l’a envoyé. Il signale une incohérence dans l’espace de séquence ; il n’en établit pas la cause.

RFC 2419 explicite ce que le texte initial disait plus brièvement : DESE vise la confidentialité seulement. Il n’apporte ni intégrité, ni authentification, ni non-répudiation, et ne garantit pas l’absence de rejeu, de découpage-collage ou de modification active. Un chiffré déchiffrable n’est donc pas nécessairement un message intact.

Le coût caché dans le MRU

DES exige des blocs de huit octets. Le champ Protocol et les données PPP doivent être complétés avant chiffrement lorsque leur longueur ne tombe pas juste. RFC 1969 autorisait du remplissage aléatoire pour les protocoles possédant leur propre longueur, tels IP, IPX, XNS ou CLNP. Pour les encapsulations où des octets terminaux changeraient le sens, il renvoyait à un remplissage auto-descriptif.

Cette règle conditionnelle demandait aux implémentations de classer correctement les protocoles internes. Le mécanisme auto-descriptif venait de RFC 1570. Elle avait aussi un cas coûteux : un texte déjà aligné dont la fin ressemble à une suite de padding peut nécessiter huit octets supplémentaires afin que le receiver ne retranche pas de vraies données.

L’exemple MRU additionne les effets. Avec PFC et un MRU initial multiple de huit, un paquet plein plus un octet de Protocol exige sept octets de padding. Les deux octets de séquence et l’enveloppe font que l’Information field DESE peut dépasser de dix octets le paquet d’origine. Or la négociation de DESE n’augmente pas automatiquement le MRU : les options PPP sont indépendantes.

Pourquoi DESE-bis reçut un nouveau numéro

Le successeur RFC 2419 indique lui-même ses différences. Il impose le même remplissage auto-descriptif à tous les textes clairs, indépendamment de l’option SDP de PPP, fixe le maximum à huit octets et demande de rejeter une trame dont la suite ne correspond pas au motif attendu.

Une ancienne implémentation pouvait interpréter différemment un paquet produit selon cette règle. DESE-bis reçut donc le Type ECP 3. L’ancien Type 1 fut déprécié ; une implémentation conforme à RFC 2419 ne doit pas l’offrir et doit le rejeter lorsqu’il est proposé. Le registre IANA PPP conserve aujourd’hui Type 1 « Deprecated (DESE) » et Type 3 « DESE-bis ».

Le remplacement ne fut pas un passage à Triple-DES. Celui-ci fut défini séparément par RFC 2420 sous le Type 2. RFC 2419 corrigeait surtout la frontière du padding et l’interopérabilité, empêchait un mélange silencieux grâce à un nouveau numéro, passait sur la Standards Track et clarifiait les limites de sécurité.

Une loi d’exportation dans la marge du RFC

RFC 1969 affirme qu’un code DES en mode ECB était disponible dans une référence, puis explique que les lois américaines d’exportation interdisaient d’inclure un code prêt à compiler dans le document. RFC 2419 garde la phrase. C’est une trace directe du régime des logiciels cryptographiques des années 1990 dans l’objet éditorial lui-même.

La preuve reste étroite : la contrainte a influencé le contenu du RFC. Elle ne démontre pas la légalité d’un produit, l’origine d’une implémentation, son exportation ou son déploiement. L’absence de code n’est ni l’absence de logiciel ni une garantie de sûreté.

Le Datatracker et RFC Editor établissent l’identité et la succession documentaire. La page des errata de RFC 1969 n’a pas livré de corps exploitable lors de la capture ; l’article ne conclut donc pas qu’il n’existe aucun erratum.

Séparer les reçus

Un dossier défendable distingue la configuration ECP, le numéro observé, le bloc terminal effectivement utilisé, le résultat de déchiffrement, la validation du padding et l’acceptation par PPP selon RFC 1661. La remise à une application et son résultat sont encore d’autres reçus.

Heng Lu invite, dans Running-Code Primacy, à relier le texte à l’exécution vérifiable avant d’élargir une affirmation. Minimum Initial Specification limite l’autorité d’un champ à sa fonction. Reality Layers et Reality, Not Advocacy empêchent de transformer un symbole en résultat ou une structure en récit de motifs. Ces textes guident l’analyse ; ils ne constituent pas des sources historiques sur DESE.