Résumé

  • Pour le modèle d’attaque décrit par la RFC 2405, raccourcir la durée d’une clé ne suffisait pas : les datagrammes IP commençaient souvent par un en-tête prévisible ou devinable.
  • DES-CBC fournissait de la confidentialité, pas de l’authentification. Vecteur d’initialisation, recherche de clé, intégrité et gestion des associations de sécurité répondaient à des questions distinctes.

Une durée de vie sans minuterie universelle

Publiée en novembre 1998, la RFC 2405 définit DES en mode CBC comme transform de confidentialité pour ESP. Elle ne fixe ni durée en heures ni volume de données maximal pour une clé. Elle laisse cette appréciation dépendre de la valeur des informations et de l’estimation des ressources adverses. Il s’agit d’un jugement de risque, pas d’une promesse que des rotations programmées rendent l’algorithme résistant.

Le texte explique le problème. Il cite la conception d’une machine à un million de dollars qui, selon une estimation de 1993, aurait pu retrouver une clé DES en trois heures et demie. Il rappelle aussi que les datagrammes IP commencent fréquemment par des octets connus ou faciles à deviner. La conclusion de la RFC est circonscrite : renouveler souvent la clé ne neutraliserait pas l’attaque à texte connu qu’elle décrit. Ces chiffres sont ceux rapportés en 1998, non un prix, un benchmark ou un essai actuel. La RFC ajoute une nuance d’époque : ESP DES-CBC protégeait tout de même davantage que l’envoi en clair.

Trois protections, trois fonctions

Chaque datagramme ESP devait porter un vecteur d’initialisation explicite de huit octets. La RFC exigeait une valeur aléatoire et interdisait un compteur ou une source dont la distance de Hamming entre valeurs successives serait faible. Le récepteur pouvait ainsi commencer à déchiffrer un datagramme même si un autre était perdu ou réordonné. Cette autonomie de paquet n’authentifiait pas le texte chiffré et n’augmentait pas la difficulté de recherche d’une clé DES.

La RFC précise que DES-CBC n’est pas un mécanisme d’authentification. Elle déconseille fortement son emploi sans authentification correspondante et décrit le risque de découpage-collage propre au CBC. Une authentification pouvait traiter ce problème d’intégrité ; changer la clé n’en était pas un substitut. La confiance dépendait aussi de l’algorithme, de son implémentation, de la gestion des associations de sécurité et de chaque nœud participant.

De l’obligation d’implémenter à « MUST NOT »

Les documents ESP ultérieurs ont modifié progressivement le vocabulaire. RFC 4305 classe DES-CBC « SHOULD NOT » alors que les exigences antérieures l’imposaient. RFC 4835 conserve ce niveau ; RFC 7321 passe à « MUST NOT » ; RFC 8221 le maintient. Cette séquence raconte l’évolution des exigences d’interopérabilité, pas la date à laquelle tous les équipements auraient cessé d’utiliser DES.

Une règle d’implémentation peut réduire la pression pour prendre en charge un algorithme à l’avenir sans effacer les systèmes en place. Spécification, configuration locale, transform négocié, traitement authentifié des paquets et mesure d’usage sont des preuves distinctes. Un paragraphe sur la durée de clé ne permet pas de les confondre.

Sources