Résumé

  • Dans la RFC 2040, le nom RC5 n'est pas une identité exécutable : W, R, b, les octets de clé, le mode, l'IV et la règle de fin doivent tous coïncider.
  • Le code, les structures ASN.1 et les vecteurs prouvent un accord borné sur des entrées précises, jamais la sécurité actuelle, l'aléa, l'unicité de l'IV, l'effacement mémoire ou le déploiement.

Publiée en octobre 1996 par Robert Baldwin et Ronald Rivest, la RFC 2040 promet assez de détails pour faire converger des implémentations distinctes de quatre constructions : RC5 brut, RC5-CBC, RC5-CBC-Pad et RC5-CTS. Son statut définit déjà la frontière. La notice du RFC Editor la classe « Informational » et précise qu'elle ne spécifie aucune norme Internet.

Le texte se présente aussi comme une reformulation de travaux existants. Sa valeur historique n'est donc pas d'attribuer une naissance à RC5. Elle réside dans la transformation d'un nom souple en contrat vérifiable.

Une identité faite de paramètres

W désigne la taille d'un mot. Le bloc B vaut deux mots et BB l'exprime en octets. R est le nombre de tours. b mesure la clé utilisateur en octets, tandis que K en contient la séquence. La table développée S comporte T = 2(R+1) mots. En CBC s'ajoute un vecteur d'initialisation I long d'un bloc.

Deux programmes peuvent donc annoncer RC5 et produire des résultats incompatibles. Il suffit qu'ils divergent sur W, R, la longueur ou l'ordre des octets de clé, le mode, l'IV ou le dernier bloc. Même le triplet W/R/b ne suffit pas sans les octets de clé effectivement liés à l'objet.

Le développement de clé rend ces dépendances visibles. Les octets sont assemblés en mots selon l'ordre petit-boutiste, S est initialisée avec des constantes dépendant de W, puis les tableaux sont mélangés pendant trois fois la plus grande de leurs longueurs. Le programme d'exemple fixe un bloc de 64 bits. Un résultat issu de ce programme appartient à ce chemin précis, pas à toutes les variantes possibles.

L'objet expose l'état caché

La RFC organise l'explication autour d'objets de clé et de chiffrement. L'objet CBC conserve le choix du bourrage, R, la clé développée, l'IV original, le bloc de chaînage courant, un bloc d'entrée partiel et son index.

Encrypt_Init lie la clé, la développe et remet la chaîne à l'IV. SetIV conserve la clé développée mais remplace l'IV, vide la position tamponnée et réinitialise la chaîne. Update accepte des fragments successifs : il retient l'incomplet, n'émet que des blocs entiers, combine chacun d'eux par XOR avec la chaîne, puis fait du résultat chiffré la chaîne suivante.

Final donne son sens à ce qui reste. En CBC simple, quelques octets résiduels constituent une erreur. En CBC-Pad, la fonction crée toujours un bloc terminal et ajoute de un à BB octets, tous égaux à leur nombre. Un message déjà aligné reçoit donc un bloc complet de bourrage. Le mode et la finalisation appartiennent à l'identité de l'opération autant que la clé.

La fin du message sépare trois machines

Le CBC ordinaire exige une longueur multiple du bloc. CBC-Pad accepte toute longueur en allongeant le résultat. CTS conserve la longueur, mais doit retenir les deux dernières portions. Il chiffre d'abord l'avant-dernier bloc chaîné, prélève dans cet intermédiaire les octets destinés au fragment final, complète le dernier fragment par des zéros, le combine avec l'intermédiaire, puis chiffre le bloc complet qui sera émis avant le fragment « volé ».

Ce n'est pas une option de présentation. Jusqu'à Final, le logiciel ignore quel bloc apparemment complet deviendra l'avant-dernier. L'objet CTS doit donc tamponner jusqu'à deux blocs.

La lecture exécutable exige les errata vérifiés. L'erratum 513 limite CTS aux textes clairs plus longs qu'un bloc. Le 514 impose l'IV lorsque le bloc chiffré antérieur n'existe pas. Le 587 rétablit dans le déchiffrement un XOR absent et la même règle de l'IV. Un code fidèle au texte original mais ignorant ces corrections peut échouer précisément sur la frontière qu'il prétend normaliser.

Des vecteurs puissants, mais étroits

La section 9 dit vouloir aider à confirmer la correction d'une implémentation. Le programme publié utilise des blocs de huit octets et lit un indicateur de bourrage, un nombre de tours, des octets de clé, un IV de huit octets et le texte clair. Les cas varient ces valeurs et donnent le chiffré attendu.

Une égalité établit quelque chose de concret : pour ce tuple exact, l'implémentation est d'accord avec la conversion de clé, le développement, la transformation du bloc, le chaînage et le chemin de finalisation observés. Une différence révèle une rupture d'accord, sans en localiser automatiquement la cause.

La portée s'arrête là. Les résultats publiés concernent CBC et CBC-Pad, pas CTS. Ils ne mesurent ni la génération de la clé et de l'IV, ni l'unicité de ce dernier, ni la résistance cryptographique, ni les effets d'un compilateur sur l'effacement mémoire, ni l'intégration dans un protocole, ni un déploiement réel.

ASN.1 ne décrit qu'une partie du dispositif

La section 11 attribue des arcs d'identifiant se terminant par 8 et 9 à CBC et CBC-Pad. La séquence de paramètres encode la version, les tours, une taille de bloc et éventuellement l'IV. En son absence, le texte définit un bloc nul de la taille choisie. L'erratum 6380 corrige les noms, la casse et la syntaxe ASN.1 sans ajouter de champ.

b, les octets de clé et la table développée n'apparaissent pas dans cette séquence. Aucun identifiant CTS n'est donné. Un OID peut donc verrouiller une partie de l'interprétation sans transporter toute l'identité d'exécution. Le défaut à zéro d'un IV est une règle de décodage historique, nullement la preuve d'une valeur aléatoire ou unique dans un système.

Ne pas transformer le code en preuve d'exploitation

Les fonctions de destruction proposées écrivent des zéros avant de libérer la mémoire. Elles attestent une intention dans la source. Elles ne montrent pas ce qu'un compilateur a conservé, ce que l'allocateur a copié ou ce qu'un processus a réellement effacé. De même, les passages de 1996 sur la sécurité et les brevets sont des traces de leur époque, pas des conclusions actuelles.

La force de la RFC 2040 est donc une force de coordination. Elle rend visibles les choix qui doivent converger. Elle devient trompeuse seulement lorsque l'accord sur quelques octets est promu en preuve de sécurité, de bonne exploitation ou d'adoption.

Sources