Résumé

  • RFC 10032 décrit quatre variantes AEGIS et trois emplois : chiffrement authentifié, génération de flot et code d’authentification de message. L’AEAD exige l’unicité du couple (clé, nonce) et interdit de livrer un texte non vérifié ; le flot jette volontairement l’étiquette ; seul le MAC autorise la réutilisation du couple sur des entrées différentes.
  • Un numéro IANA, un vecteur de test ou une mesure de vitesse atteste au mieux une coordination ou une transformation. Il ne prouve pas que l’application a choisi le bon rôle, isolé les clés, réservé le bon espace de nonces et retenu les sorties avant vérification.

La refonte paraît raisonnable. Les trois chemins utilisent la même famille, les mêmes blocs AES et des paramètres voisins. Une interface unique réduit le code. Mais elle transforme une ressemblance interne en promesse externe. Dès que l’appelant ne peut plus dire quel rôle il invoque, l’exception du MAC peut contaminer le chiffrement, et le flot peut hériter d’un mot « authentifié » qui ne lui appartient pas.

RFC 10032, publié sur le flux IRTF comme document informatif et fruit du consensus du CFRG, coordonne les algorithmes AEGIS-128L, AEGIS-256, AEGIS-128X et AEGIS-256X. Il ne s’agit pas d’une norme IETF imposant un déploiement. Les modes X exploitent les registres vectoriels et les instructions AES ; leur disponibilité reste une décision de profil et d’implémentation.

IANA a attribué les identifiants AEAD 32 à 37 aux variantes de base et parallèles. Ces nombres donnent des noms stables. Ils ne choisissent pas le rôle de l’API, la longueur d’étiquette, le schéma des données associées, le domaine de nonce ou la conduite à tenir après un échec. L’article BTW déjà publié sur RFC 10032 possède précisément la frontière entre codepoint, négociation et usage réel. Le présent dossier commence après cette sélection : que signifie effectivement la sortie de la fonction appelée ?

L’AEAD place une barrière avant le texte clair

Dans le rôle AEAD, le chiffrement reçoit message, données associées, clé et nonce ; il rend texte chiffré et étiquette. Le déchiffrement recalcule l’étiquette, la compare en temps constant et ne peut rendre le texte clair qu’après réussite.

Le couple clé-nonce ne doit servir qu’une fois au chiffrement. Changer de 128 à 256 bits d’étiquette ne recrée pas un espace de nonce. Une réutilisation révèle immédiatement la différence binaire entre deux messages et permet la récupération de l’état dans le scénario décrit. Le nonce peut être public et prévisible : son secret importe moins que son unicité.

Pour AEGIS-128L et AEGIS-128X, le RFC donne un repère de 2^48 messages avec des nonces aléatoires sous une même clé pour une probabilité de collision d’environ 2^-33. Pour AEGIS-256 et AEGIS-256X, il ne voit pas de limite pratique à cet usage aléatoire. Cette phrase ne transforme jamais une répétition intentionnelle en opération sûre.

L’autre invariant se trouve à la sortie. Si l’étiquette échoue, le texte provisoire et l’étiquette calculée ne doivent pas être livrés ; le tampon déchiffré doit être écrasé. Un parseur appelé avant la vérification, un journal contenant quelques octets ou une écriture en base déjà déclenchée franchissent la barrière, même si la fonction publique finit par répondre « erreur ».

La preuve utile relie donc le rôle, la variante, la clé, l’allocation du nonce, l’encodage des données associées, la longueur d’étiquette, le résultat de vérification et toutes les sorties latérales. Une étiquette valide juge un tuple de bits sous une clé. Elle ne surveille pas l’architecture de l’application.

Le flot abandonne l’authentification par construction

Le mode flot de RFC 10032 chiffre une suite de zéros sans données associées et jette l’étiquette. Une implémentation peut même omettre l’étape de finalisation. Le résultat est un flot de clés utilisable par une construction supérieure.

Cette fonction n’est pas défectueuse. Elle offre simplement une autre propriété. Le flot ne constitue pas un message authentifié, ne prouve pas l’origine d’une donnée et ne fournit aucun reçu de vérification. Si une application combine ces octets avec un texte, elle doit désigner ailleurs le mécanisme d’intégrité, l’ordre des opérations et la barrière de livraison.

Le risque vient du vocabulaire. Un inventaire indique « protégé par AEGIS » ; la trace ne précise pas Stream. Une migration conserve la valeur algorithm=aegis mais remplace Encrypt par Stream. Une autre équipe cherche une étiquette qui a été supprimée par définition.

Le rôle flot mérite donc sa propre clé, son propre espace de nonce et un type de sortie explicite — « flot non authentifié » — plutôt qu’un tableau d’octets anonyme. Le nom de la primitive ne doit pas prêter au flot la promesse de l’AEAD.

Le MAC possède l’unique exception de réutilisation

Le MAC absorbe les données et produit une étiquette de 128 ou 256 bits. RFC 10032 indique que cette fonction, et elle seule, permet de réutiliser un couple (clé, nonce) avec des entrées différentes.

Le sujet grammatical de la règle compte. Ce n’est pas « AEGIS » en général ; c’est la fonction MAC. Une politique unique de nonce pour toute la famille peut importer cette permission dans le chiffrement. L’algorithme calculera néanmoins un résultat : il ne connaît pas l’autorité que le logiciel lui a attribuée.

L’étiquette MAC connaît aussi ses limites. Elle ne doit pas servir de hachage lorsque la clé est connue, car des entrées provoquant des collisions d’état peuvent être construites. Elle ne doit pas devenir matériau de dérivation de clé, car sa distribution uniforme n’est pas garantie. Sa longueur ne lui confère pas ces fonctions.

Le meilleur contrôle est matériel dans l’architecture : identifiants de clés liés au rôle, libellés de dérivation distincts, allocateurs de nonce séparés et refus d’une clé AEAD par les interfaces STREAM et MAC. Demander aux développeurs de se souvenir d’une exception noyée dans une documentation n’est pas une séparation de pouvoirs.

La longueur d’étiquette ne résout pas l’autorité

RFC 10032 autorise 128 et 256 bits. Il décrit environ 64 bits de sécurité d’engagement de clé avec l’étiquette courte et environ 128 avec la longue dans le jeu considéré. Le codepoint ne révèle pas ce choix.

L’engagement dépend aussi des données associées. AEGIS est pleinement engageant dans le cas restreint où l’adversaire ne les contrôle pas. S’il peut les modifier, l’analyse citée permet de trouver efficacement plusieurs clés validant le même texte chiffré authentifié. Un protocole qui exige une propriété plus forte peut hacher les données associées avec une fonction appropriée ou les lier par le champ info d’une KDF avec un encodage sans ambiguïté.

Ce sont des décisions du protocole. Il faut connaître les champs, leur sérialisation, qui les contrôle et quelle propriété l’application réclame. Le chiffrement authentifie les bits reçus, pas l’interprétation institutionnelle de ces bits.

Les vecteurs s’arrêtent avant la garde des sorties

Les nombreux vecteurs de RFC 10032 démontrent qu’une implémentation produit la sortie attendue pour une entrée fixée. Ils ne montrent pas que la production appelle la bonne fonction ni que son chemin d’échec reste fermé.

Une recette de déploiement doit vérifier les confusions de rôles : refus d’une clé dans un rôle non autorisé ; rejet d’un nonce de chiffrement répété malgré un changement d’étiquette ; isolation de l’exception MAC ; typage du flot comme non authentifié ; absence de texte, callback ou effet secondaire après une étiquette corrompue ; refus des tags MAC par les interfaces de hachage et KDF ; identité du binaire chargé et du chemin CPU ; compteurs distincts pour chaque rôle.

La résistance aux attaques temporelles, physiques et par faute dépend du AESRound réellement exécuté et du modèle de menace. La possibilité d’effacer une clé éphémère après l’initialisation n’est pas la preuve qu’un compilateur ou une bibliothèque l’a fait. C’est un autre reçu de code en fonctionnement.

Le dossier minimal d’un appel AEGIS doit joindre : but de l’application, rôle, variante, degré de parallélisme, longueur d’étiquette, identité et finalité de clé, allocation du nonce, schéma des données associées, version et chemin d’implémentation, résultat de vérification et d’effacement, frontière de sortie, compteurs et décision finale de l’application.

La doctrine de spécification minimale de Lu Heng place chaque décision chez l’acteur qui en porte les conséquences. Le registre nomme. La bibliothèque exécute. Le protocole structure. L’application autorise l’action. La discipline des couches de réalité empêche un RFC, un test ou un tag de s’emparer de l’autorité de la couche suivante.

RFC 10032 montre ainsi quelque chose de plus général qu’une nouvelle famille rapide : une même mécanique peut offrir plusieurs services sans créer un contrat unique. Le nom reste stable ; les reçus doivent rester séparés.

Sources