Résumé

  • RFC 9861 définit quatre XOF, mais le nom de la famille ne suffit pas : il faut aussi connaître les octets d’entrée, le séparateur de domaine ou la personnalisation et la longueur de sortie.
  • Pour KT128 et KT256, l’entrée encodée, et non le seul message, détermine le passage du nœud unique à l’arbre au-delà de 8192 octets.
  • Le statut Informational de l’IRTF et les enregistrements IANA stabilisent une référence ; ils ne certifient ni un binaire, ni un protocole, ni un déploiement.

Le premier système avait archivé une valeur et le mot KT128. Le second avait le même fichier et le même mot. Il ne parvenait pourtant pas à reproduire la valeur.

La panne documentaire pouvait tenir dans un champ absent : une chaîne de personnalisation non vide. Elle pouvait aussi venir d’une sortie demandée sur 64 octets au lieu de 32, d’un encodage différent ou d’un adaptateur qui avait réassemblé les fragments dans un autre ordre. Le nom commun n’avait pas menti ; il n’avait simplement jamais décrit toute l’opération.

RFC 9861, publié en octobre 2025, fixe la définition de TurboSHAKE128, TurboSHAKE256, KT128 et KT256. Le registre RFC le classe Informational dans le flux IRTF. Il représente un consensus du Crypto Forum Research Group, pas une norme Internet de l’IETF. Cette précision n’est pas une note administrative : elle sépare une référence commune d’une décision locale d’adoption.

La longueur n’est pas une option d’affichage

TurboSHAKE reçoit un message M, un octet de séparation de domaine D et une longueur positive L. D vaut 1F par défaut et doit rester entre 01 et 7F. À message et domaine identiques, une sortie courte est le préfixe d’une sortie plus longue.

Cette propriété ne rend pas les longueurs interchangeables. Un protocole qui attend 32 octets n’a pas automatiquement autorisé 64 octets, pas plus qu’une base qui tronque une valeur n’a défini une migration. La longueur appartient au contrat cryptographique. Elle doit figurer avec la variante, le domaine, la sérialisation et la règle de comparaison.

Les interfaces progressives posent la même question sous une autre forme. RFC 9861 permet de fournir M par morceaux, à condition que le résultat soit celui de leur concaténation dans l’ordre. Il permet aussi de lire la sortie par morceaux, à condition que leur concaténation corresponde à une demande unique de longueur totale. Les limites de tampon peuvent changer ; l’ordre des octets ne le peut pas.

La personnalisation participe au calcul

KangarooTwelve utilise une chaîne C à la place de l’octet de domaine. La construction forme de manière réversible S = M || C || length_encode(|C|). Le nom d’un service, un URI ou un identifiant de tenant placé dans C n’est donc pas un commentaire autour de l’empreinte : il contribue aux octets qui la déterminent.

Une organisation doit savoir qui choisit cette chaîne, quel encodage elle emploie et comment elle évolue. Une normalisation d’URI, un passage d’UTF-8 à une autre représentation ou l’effacement d’un champ jugé « descriptif » produit une autre sortie conformément à la spécification. Le tableau de bord peut continuer d’afficher KT256 et masquer une rupture réelle.

Le vide mérite lui aussi un statut. C vide peut être un choix explicite, la valeur imposée par une API qui n’expose pas la personnalisation, ou une information perdue. Le calcul du jour peut être identique ; la capacité à migrer demain ne l’est pas.

Le seuil de l’arbre se calcule après l’encodage

KT128 et KT256 découpent S en blocs de 8192 octets. Jusqu’à cette taille, le chemin reste à un nœud. Au-delà, les blocs suivants deviennent des valeurs de chaînage, puis rejoignent le premier bloc dans un nœud final. KT128 utilise des valeurs intermédiaires de 32 octets ; KT256, de 64.

Le seuil concerne S, qui comprend C et l’encodage de sa longueur. Modifier uniquement la personnalisation peut donc faire changer la topologie interne sans toucher au message métier. C’est précisément le type de bord que les tests doivent couvrir : juste avant, exactement au seuil et juste après, avec personnalisation vide puis non vide.

Une implémentation peut paralléliser les branches. Elle ne peut pas produire une réponse différente. L’accélération SIMD, le changement de processeur ou un backend matériel sont des paramètres d’exécution à enregistrer, tandis que l’égalité finale demeure l’invariant partagé.

Les noms fixes ferment une partie du contrat

Dans le registre IANA Named Information, k12-256 désigne précisément KT128 avec C vide et 32 octets de sortie ; k12-512 désigne KT256 avec C vide et 64 octets. Ces profils sont plus précis que le simple nom KT128.

Le registre COSE attribue aussi des valeurs à TurboSHAKE128, TurboSHAKE256, KT128 et KT256. Un numéro permet aux systèmes de parler du même mécanisme. Il ne raconte pas les octets reçus, les paramètres fixés par le protocole, la version de la bibliothèque ou le résultat des essais.

La même retenue s’impose face aux affirmations de sécurité. RFC 9861 revendique 128 bits pour les variantes 128 et 256 bits pour les variantes 256, en s’appuyant sur l’analyse de Keccak à 12 tours et sur le codage Sakura. FIPS 202 fournit la base Keccak/SHA-3 ; SP 800-185 décrit des fonctions dérivées voisines. Cette filiation n’est pas un certificat pour un binaire local ni une preuve de résistance aux canaux auxiliaires d’une machine donnée.

L’erratum montre pourquoi les paramètres doivent être nommés

Les vecteurs de RFC 9861 couvrent plusieurs tailles, personnalisations et frontières de l’arbre. Le registre d’errata contient actuellement l’erratum technique 8997, encore au statut Reported. Il relève que plusieurs appels de test KT omettent l’étiquette explicite M= alors que le premier argument reste positionnel. La correction proposée harmonise l’écriture des paramètres ; elle ne remplace pas les octets de sortie affichés.

Il faut conserver ce statut exact. « Signalé » ne signifie pas « vérifié », et une proposition de clarification n’est pas déjà intégrée au texte immuable. Le reçu de conformité associe chaque vecteur à ses arguments complets, au résultat attendu, au résultat observé, au binaire et au chemin matériel.

L’égalité des octets ne décide pas de l’usage

Même un test parfait ne prouve pas l’auteur du message, sa fraîcheur, la garde d’une clé ou l’autorisation d’une action. RFC 9861 décrit HopMAC et permet également d’autres placements réversibles de la clé. L’étiquette « MAC KT128 » reste ambiguë sans construction exacte, identifiant de clé, longueur de tag, domaine et hypothèses de protection.

La hiérarchie correcte est plus exigeante : la spécification définit, la configuration choisit, le code exécute, le test compare, le protocole accepte et l’application agit. Une empreinte ne doit recevoir l’autorité de toutes ces couches que si leurs reçus peuvent être reliés sans être confondus.

Sources