Résumé

  • RFC 9771 répartit les adjectifs courants de l’AEAD en quatre familles de promesses ; les confondre transforme une affirmation vraie sur un algorithme en message trompeur à la frontière du système.
  • Une décision défendable exige un reçu de propriété reliant précisément la notion de sécurité, la construction et sa version, le comportement de l’API, les tests négatifs, le cycle de vie des clés et l’intégration protocolaire.

L’adjectif n’a jamais constitué la garantie

« Chiffrement authentifié » donne l’impression qu’une décision de sécurité est achevée. Ce n’est qu’une primitive dont la protection dépend d’un contrat entre algorithme, discipline des clés et nonces, données associées, interface et état du protocole. Publié en mai 2025 par le Crypto Forum Research Group de l’IRTF, RFC 9771 refuse justement de réduire ce contrat à une seule marque de qualité.

Le texte est informatif : ce n’est ni une norme Internet ni une certification de déploiement. Sa force est taxonomique. Il sépare la sécurité conventionnelle des propriétés qui résistent à un adversaire doté de capacités supplémentaires, puis distingue les deux des propriétés d’implémentation et des fonctions qui changent l’interface. L’acheteur peut ainsi identifier la nature de la phrase entendue avant de décider quelle preuve elle réclame.

L’interface conventionnelle de RFC 5116 reçoit une clé, un nonce, des données associées et un texte clair ; le déchiffrement rend le clair ou un échec. Elle contient déjà une obligation opérationnelle : chaque invocation sous une clé doit employer un nonce unique. Une fiche indiquant « AES-GCM » ne dit pas qui en est responsable, ce qui arrive après restauration d’un instantané, comment plusieurs émetteurs partagent l’espace, ni si accélérateur et repli logiciel partagent le même état.

RFC 9771 enrichit donc le vocabulaire sans abolir les questions. Ce n’est pas un catalogue où l’accumulation d’adjectifs produirait automatiquement davantage de sûreté, mais une carte d’obligations de preuve distinctes.

Quatre familles, quatre dossiers de preuve

Famille Ce que la promesse modifie Preuve à fournir
Sécurité conventionnelle Confidentialité et intégrité de base Construction, paramètres, notion formelle, bornes concrètes, vecteurs et limites d’usage
Propriété de sécurité supplémentaire Capacités accrues : répétition de nonce, multi-utilisateur, fuite ou clair anticipé Volets confidentialité/intégrité, notion formelle, écarts de notions et tests propres au mésusage
Propriété d’implémentation Manière d’exécuter le calcul Chemin réellement mesuré, mémoire, passes, frontière de vérification, parité matériel/repli
Fonction supplémentaire Nouvelle interface : mise à jour ou expansion réglable du chiffré Contrat d’API, notion conventionnelle révisée, transitions d’état, compatibilité et échecs

Cette division révèle une erreur fréquente. « Une passe », « parallélisable » et « diffusable en continu » décrivent le calcul ; ces termes ne prouvent pas la confidentialité ou l’intégrité. RFC 9771 signale qu’une construction diffusable peut aussi nécessiter la sécurité par blocs et l’intégrité lorsque du clair non vérifié est libéré. Un banc d’essai de débit n’est donc pas le reçu de sécurité d’une API de streaming.

L’erreur inverse existe : un résultat formel sur la construction ne prouve pas que son enveloppe le préserve. Si le déchiffreur livre des octets avant validation de l’étiquette, l’application entre dans le modèle RUP, où du clair non vérifié est libéré. La confidentialité conventionnelle devient impossible ; les objectifs d’intégrité et de connaissance du clair changent. Deux API utilisant la même primitive, l’une tamponnée et l’autre incrémentale, peuvent donc soutenir des promesses différentes.

Les fonctions supplémentaires rendent la frontière encore plus visible. RFC 9771 place le chiffrement authentifié incrémental et le chiffrement authentifié robuste dans une annexe parce qu’ils dépassent l’interface conventionnelle. Dans le second, l’appelant choisit l’expansion du chiffré afin d’obtenir la meilleure intégrité possible pour cette longueur. Ici, « robuste » ne signifie pas « robustesse de clé », parfois synonyme d’engagement sur la clé. Un dossier qui ne conserve que le mot a déjà perdu l’information utile.

Les quasi-synonymes cachent les hypothèses

Résilience au mésusage des nonces et résistance au mésusage des nonces paraissent interchangeables. RFC 9771 dit le contraire. La résilience protège les messages dotés d’un nonce frais même si un adversaire provoque des répétitions ailleurs. La résistance protège aussi les messages qui subissent la répétition, sauf la fuite inévitable lorsque le même clair est répété sous le même nonce. La résistance implique la résilience, pas l’inverse.

Le plan de test en dépend. Pour la résilience, il faut montrer qu’un incident ne contamine pas le trafic à nonce frais. Pour la résistance, il faut en plus caractériser le trafic affecté. AES-GCM-SIV dans RFC 8452 est une construction standardisée résistante au mésusage ; cela ne transfère pas la propriété au GCM ordinaire et ne prouve rien sur la gestion des clés ou des erreurs par l’intégration.

Même piège pour l’engagement. L’engagement sur la clé demande si un même chiffré peut être valide sous différentes clés. L’engagement complet inclut aussi nonce, données associées et clair. Le complet implique celui sur la clé, pas l’inverse. Cette différence devient opérationnelle quand une application se sert d’un déchiffrement réussi pour découvrir le locataire, le compte ou le contexte. Les travaux sur la découverte de contexte montrent que l’ambiguïté entre plusieurs contextes valides est concrète. Pourtant, le reçu doit encore préciser construction, encodage du contexte, longueur d’étiquette et notion de preuve : un mot ne lie pas ce que le système n’a pas encodé.

Construire le reçu de propriété

Le reçu est un objet de preuve compact et versionné, lisible par les achats, l’ingénierie sécurité, l’exploitation et la réponse aux incidents. Il commence par le nom exact de la propriété et sa famille RFC 9771. « Confidentialité et intégrité résistantes au mésusage de nonce » est une promesse ; « nonces plus sûrs » est une accroche. Si confidentialité et intégrité reposent sur des notions différentes, les deux doivent apparaître. Pour une notion alternative, RFC 9771 demande une preuve d’équivalence ou la divulgation de la non-équivalence.

Il fige ensuite l’objet : algorithme, construction, paramètres, longueur d’étiquette, fournisseur ou bibliothèque, version, build, chemin CPU ou accélérateur et repli logiciel. Une preuve de conception et un test d’un binaire répondent à des questions distinctes ; il faut conserver les deux.

La section d’interface précise les entrées, le moment de libération de la sortie, la frontière de vérification, l’ordre des fragments, l’annulation et les erreurs. Elle attribue la construction des nonces et des données associées. Savoir si un échec ne produit rien, produit du tampon, livre une partie du clair ou survient après l’action de l’appelant détermine le modèle de sécurité réel.

Les tests négatifs doivent dériver de la propriété : nonce répété, mauvaise clé, données associées altérées, chiffré d’un autre contexte, étiquette tronquée ou forgée, fragments réordonnés, sortie prématurée, retour arrière du processus, restauration, épuisement du compteur, changement de phase de clé et désaccord entre logiciel et accélérateur. Un résultat observé n’est pas une preuve ; une preuve n’atteste pas que l’API en respecte les prémisses.

Le cycle de vie couvre génération et dérivation, identité de clé, portée des nonces et séquences, concurrence, plafonds d’usage, rotation, destruction, sauvegarde, restauration et agrégation multi-utilisateur. RFC 8645 décrit des mécanismes de rechiffrement, mais le déploiement doit montrer le déclencheur choisi et le chevauchement des états. Tout changement de fournisseur, d’accélérateur, d’allocateur de nonce, de persistance ou de rotation doit faire expirer le reçu.

Enfin, l’intégration protocolaire fournit la preuve entre primitive et réseau. TLS 1.3 construit les nonces de records à partir de séquences ; QUIC ajoute numéros de paquets et phases de clé. Reprises, anti-rejeu, récupération, migration, cadrage, liaison de contexte, interopérabilité et terminaison matérielle sont donc des faits à établir séparément.

La demande que l’acheteur peut formuler

RFC 9771 permet désormais de demander : « Pour chaque propriété AEAD non conventionnelle revendiquée, fournissez la notion exacte, l’implémentation et la version concernées, le comportement d’API qui préserve les prémisses, les tests négatifs de frontière, les contrôles du cycle de vie des clés et les chemins protocolaires couverts. »

Dire qu’une propriété n’est pas prise en charge, ne vaut que pour un chemin ou reste non démontrée dans un mode de panne est une réponse utile. Elle crée une frontière tarifable, surveillable et révisable. Le danger vient d’un nom sans responsable ni date d’expiration : un résultat conditionnel devient alors une mémoire institutionnelle permanente.

Sources