Résumé

  • RFC 10032 est un document informatif du flux IRTF, issu du consensus du CFRG. Il ne constitue ni une norme IETF ni une obligation générale de déploiement.
  • Les identifiants 32 à 37 distinguent AEGIS-128L, AEGIS-256 et quatre formes parallèles X2/X4. Ils ne portent pas le choix entre un tag de 128 et de 256 bits.
  • Les modes parallèles sont facultatifs et le RFC recommande de ne les choisir que lorsque toutes les parties s’accordent sur la variante précise.
  • La preuve d’exploitation doit relier le profil du protocole, la sélection authentifiée, le code, le tag, les clés, les nonces, les données associées, le binaire exécuté, les tests négatifs, les compteurs et le retour arrière.

Un registre résout un conflit de noms

Le registre AEAD de l’IANA remplit une fonction étroite et essentielle : un identifiant public ne doit pas désigner deux constructions incompatibles. RFC 10032 ajoute six entrées. Les valeurs 32 et 33 couvrent les formes de base ; 34 à 37 couvrent les degrés de parallélisme deux et quatre des familles 128 et 256.

Cette coordination ne crée pas une négociation. RFC 5116 précise qu’un enregistrement IANA ne vaut pas approbation de l’algorithme ni de sa sécurité. Son interface AEAD laisse aussi hors de son périmètre les décisions d’anti-rejeu et de contrôle d’accès. Le protocole appelant doit donc définir quand l’identifiant est offert, comment la sélection est protégée et quels paramètres l’accompagnent.

Le 20 septembre 2026, le registre public présentait bien les six valeurs, mais sa colonne de référence pointait encore vers la révision 18 du projet et la page indiquait une dernière mise à jour au 7 juillet. Cette observation datée n’annule pas les numéros. Elle montre que l’état de publication et l’état affiché du registre sont deux preuves distinctes, à conserver séparément.

« RFC » ne désigne pas un seul niveau d’autorité

RFC 10032 est publié dans le flux IRTF, en catégorie Informational. Le texte dit qu’il reflète le consensus du Crypto Forum Research Group, qu’il n’est pas un produit de l’IETF et qu’il n’est pas une norme. Le préambule ajoute que les résultats de recherche de l’IRTF peuvent ne pas convenir au déploiement.

RFC 5743 décrit la préparation par le groupe de recherche, l’examen par l’IRSG puis le contrôle de conflit par l’IESG. RFC 7841 explique pourquoi un document d’un flux autre que l’IETF ne doit pas être confondu avec une norme issue d’un dernier appel IETF et de l’approbation de l’IESG.

Il faut donc séparer quatre faits : le CFRG a dégagé un consensus de recherche ; l’IRSG a approuvé la publication ; l’IESG a vérifié l’absence de conflit avec la normalisation ; l’IANA a attribué des nombres uniques. Aucun de ces faits ne prouve qu’un protocole précis a adopté AEGIS, qu’un produit l’a activé ou qu’une session l’a utilisé.

Cette séparation rejoint une règle de conception plus générale : une publication facilite la coordination, mais la réalité opérationnelle apparaît seulement lorsque des participants implémentent, valident, déploient et utilisent une option compatible.

Le tag absent du nom public

AEGIS-128L utilise une clé et un nonce de 128 bits. AEGIS-256 emploie 256 bits pour les deux. Les deux familles acceptent un tag d’authentification de 128 ou 256 bits. Or les noms du registre ne comportent pas cette longueur.

Deux pairs peuvent donc afficher le même codepoint tout en interprétant différemment la limite entre texte chiffré et tag. Le RFC autorise deux représentations : structures séparées, ou concaténation où le tag suit immédiatement le texte chiffré. Sans profil précis, l’égalité du numéro ne garantit pas l’égalité du format.

Le choix influe aussi sur la propriété de commitment décrite par RFC 10032. Le document évalue à environ 2^64 l’effort pour trouver des clés ou nonces distincts validant le même triplet avec un tag de 128 bits, et à environ 2^128 avec 256 bits. Ce n’est donc pas un détail que l’on peut déduire après coup du nom AEAD_AEGIS128L.

Les données associées demandent la même discipline. RFC 5116 cite les adresses, ports, séquences et versions de protocole comme exemples de champs clairs mais authentifiés. L’ordre, la longueur, la version de schéma et la séparation de domaines font partie du contrat d’interopérabilité. Un tampon AD accepté par une bibliothèque ne prouve pas que les deux côtés ont sérialisé la même réalité.

Le parallélisme n’est pas une simple optimisation locale

Les formes AEGIS-128X et AEGIS-256X visent les processeurs dotés de grands registres vectoriels et d’instructions AES vectorielles. Les variantes X2 et X4 représentent des degrés différents, avec des tailles d’état et des débits distincts.

Le texte conserve pourtant AEGIS-128L et AEGIS-256 comme choix par défaut. Il dit que les protocoles ne devraient retenir un mode parallèle que lorsque toutes les parties conviennent de la variante exacte, et autorise une implémentation à ne pas inclure ces modes.

Un résultat de benchmark X4 ne vaut donc ni capacité du pair distant ni preuve du chemin exécuté. Une image de machine virtuelle peut perdre une instruction lors d’une migration. Un binaire peut être compilé sans le chemin X4. Un répartiteur d’exécution peut tomber sur le code de base tout en laissant la configuration générale à « AEGIS ». Le dossier doit distinguer ce qui a été négocié, ce que chaque pair pouvait exécuter et ce qui a réellement tourné.

La garde du nonce ne disparaît pas avec 256 bits

Pour le chiffrement, RFC 10032 interdit de réutiliser un nonce avec une même clé, y compris entre deux longueurs de tag. La réutilisation révèle immédiatement la différence bit à bit entre deux messages. Le nonce peut être public ou prévisible ; un compteur est permis.

Le texte donne des marges généreuses aux nonces aléatoires : jusqu’à 2^48 messages par clé pour la famille 128 avec la probabilité indiquée, et aucune limite pratique pour la famille 256. Mais une grande taille ne résout pas l’exploitation d’un clone de machine, d’un compteur restauré ou de deux processus qui croient posséder la même plage.

La preuve doit nommer le domaine d’unicité, l’époque de clé, la persistance au redémarrage, la source aléatoire, les compteurs et les événements de restauration. Elle doit aussi fixer la dérivation de clé, le contexte de protocole et le moment d’effacement. Sans ces éléments, « nonce 256 bits » reste une propriété de format, pas une garde opérationnelle.

Les vecteurs testent la primitive, pas la session

L’annexe de RFC 10032 fournit des vecteurs pour la ronde AES, les modes de base, les variantes X2/X4 et les MAC. Ils détectent efficacement les erreurs d’ordre des octets, de finalisation, de bloc partiel et de tag. Des essais croisés entre bibliothèques ajoutent une preuve d’interopérabilité sur des entrées fixes.

Il faut également modifier le tag, les données associées, le nonce et la variante pour vérifier le refus. Le RFC exige qu’un échec d’authentification ne libère ni le texte non vérifié ni le tag calculé, que le tampon déchiffré soit effacé et que la comparaison du tag s’effectue en temps constant.

Même une campagne parfaite ne prouve pas le trafic réel. Il manque encore la sélection du protocole, le chargement du bon binaire, le chemin matériel, la continuité du compteur et le lien avec une session bornée. Le test dit « cette fonction calcule correctement ». Il ne dit pas « cette fonction a protégé ce flux ».

Le reçu de garde algorithmique

Le reçu proposé ici est une recommandation éditoriale de Daniel Kade, non une exigence du RFC.

Il doit d’abord conserver l’identité du document, son flux, sa catégorie, l’instantané d’errata et l’instantané IANA. Il nomme ensuite le protocole appelant, sa version, son profil de suite et sa génération de configuration, puis attache la preuve authentifiée de l’offre et de la sélection.

Il enregistre le code numérique, la variante exacte, le degré X2/X4, la longueur de tag et le cadrage. Il conserve les capacités des pairs et le comportement face à une variante absente. Il documente l’origine et l’époque de la clé, le contexte de dérivation, l’identifiant éventuel et la frontière d’effacement.

Le même reçu décrit la construction du nonce, sa persistance, son domaine d’unicité, le redémarrage et le compteur par clé. Il fige la liste et l’encodage canonique des données associées. Il identifie la bibliothèque, le build, le chemin CPU et le repli. Il joint les vecteurs positifs, les essais croisés, les tests négatifs et le comportement d’échec.

Enfin, il relie ces preuves à une session ou à un ensemble borné de paquets, conserve les limites d’usage, et précise repli, refus de downgrade, déclencheur de rollback et durée de rétention. C’est cette jointure qui transforme une capacité déclarée en affirmation révisable.

Sources