Résumé

  • La révision 13 ajoute explicitement les données authentifiées associées au volume de texte clair. Compter seulement la charge chiffrée revient à mesurer une autre grandeur que celle de la limite.
  • Messages protégés, vérifications infructueuses, nonces, population de clés et exposition maximale d’une clé sont des preuves distinctes qu’un compteur local à une connexion peut désunir.
  • Les formules et tableaux sont illustratifs. Le seuil de risque appartient à l’application; le déploiement doit prouver le comptage, le refus, l’activation et le retrait dans le code exécuté.

Une formule ne fait pas fonctionner le compteur

Le Crypto Forum Research Group a publié le 3 septembre 2026 la révision 13 de Usage Limits on AEAD Algorithms. Le texte affirme désormais son statut de produit du consensus du CFRG, mais reste un Internet-Draft de l’IRTF. Il peut encore changer, expirer ou ne jamais devenir RFC.

Son point de départ est simple : l’usage répété d’une même clé augmente l’avantage disponible pour un attaquant. La difficulté commence lorsqu’il faut transformer cette proposition en règle d’admission. RFC 5116 normalise l’interface de l’AEAD — clé, nonce, texte clair et données associées — mais ne compte pas le travail d’un parc de services. Il ignore les redémarrages, les répliques, les paquets rejetés et le périmètre multiclés.

La révision ne remet donc pas le pouvoir d’exploitation au groupe de recherche. Elle fournit un langage commun. Le choix du risque acceptable et la preuve que les limites gouvernent le trafic restent chez l’opérateur.

« Suffisamment faible » est une décision de l’application

Le projet distingue les avantages liés au chiffrement authentifié, à la confidentialité et à l’intégrité. L’application fixe leur niveau acceptable, puis dérive les limites opérationnelles à partir de la construction et des paramètres de son déploiement.

Un tableau d’exemple n’est pas une politique prête à copier. Ses nombres reposent sur une taille de message, un travail hors ligne et une probabilité cible déterminés. Une étiquette plus courte peut rendre les tentatives de vérification infructueuses plus contraignantes que le trafic réussi. Un changement d’hypothèse change le budget.

Il faut donc conserver avec le seuil le nom exact de l’algorithme, la taille de l’étiquette, l’enveloppe des messages, le travail adverse supposé et la définition du périmètre de clés. Sans ces éléments, le voyant « 62 % consommés » n’a aucune signification auditable.

AAD fait partie de la dépense

La révision 13 définit s comme le volume total du texte clair et des données authentifiées associées, et L comme la longueur maximale couvrant les deux. Le changement corrige une ambiguïté d’exploitation réelle.

AAD reste visible, mais entre dans le calcul d’authentification. En-têtes, contexte, numéros de séquence ou métadonnées peuvent donc consommer du travail cryptographique sans apparaître dans le corps chiffré. Une plateforme qui facture seulement les octets de charge utile sous-estime son exposition.

CCM le montre directement : le travail sous-jacent inclut les blocs d’AAD, de texte chiffré et de texte clair, plus une opération. Le projet emploie une approximation prudente 2L. La formule est propre à la construction; la discipline générale consiste à ne pas confondre trafic visible et quantité de sécurité.

Réussites et rejets ne consomment pas la même réserve

q compte les messages protégés; v les déchiffrements ou tentatives de contrefaçon infructueux. Les écrivains observent le premier nombre. Les lecteurs et vérificateurs rencontrent le second. Si les équipes ou processus ne partagent pas un même registre, une moitié du budget disparaît.

Le cas AES-CCM_8 est éclairant. Son étiquette de 64 bits peut faire de v la ressource rare. La valeur 2^13 du tableau à clé unique est une illustration sous des hypothèses précises, pas un seuil universel. Le fait important est qu’un trafic hostile rejeté peut épuiser une autorité que les métriques de succès ne voient jamais.

Le compteur doit donc avancer avant que le rejet ne fasse disparaître la requête. Une protection anti-débit peut réduire l’exposition, mais elle ne remplace le registre cryptographique que si elle couvre exactement les opérations et les clés analysées.

Une clé et une population de clés

La section 6 concerne une seule clé. Le texte interdit d’utiliser ces limites lorsque plusieurs clés existent, y compris après renouvellement dans une connexion ou à travers plusieurs connexions. La section 7 considère l’attaquant satisfait par la rupture de n’importe quelle clé.

La rotation réduit l’activité sous une clé, tout en agrandissant la population étudiée. Les limites multiclés demandent des totaux q et v, mais aussi, selon la construction, le maximum de blocs traités par une clé : B pour le chiffrement, C pour chiffrement et déchiffrement. La moyenne du parc cache une clé chaude; les seuls compteurs individuels cachent l’avantage de viser l’une des nombreuses clés.

Ni un redémarrage de conteneur, ni un basculement régional, ni un déplacement de locataire ne doit créer un budget neuf si le modèle cryptographique n’a pas changé. Le périmètre suit les clés et l’analyse, pas la commodité du tableau de bord.

Le nonce reste un verrou indépendant

Pour GCM notamment, répéter un nonce sous la même clé peut briser confidentialité et intégrité. Être loin d’un seuil de volume ne rend pas cette répétition acceptable. L’allocation des nonces exige sa propre preuve de concurrence, persistance après panne et comportement après retour arrière.

La révision 13 précise aussi que, pour GCM, la condition s + q + v < 2^64 peut devenir la contrainte active lorsque le terme dérivé de la probabilité approche ce plafond. L’admission doit respecter la première condition atteinte, pas le compteur le plus facile à afficher.

La rotation est une séquence, non un événement

Une clé est créée, distribuée, activée pour protéger de nouveaux messages, puis retirée de l’acceptation. Ces quatre instants diffèrent. Des lecteurs peuvent encore avoir besoin de l’ancienne clé lorsque les écrivains ont basculé; des opérations en vol traversent la frontière.

Le contrôle doit réserver de la marge pour la télémétrie en retard, la concurrence, les reprises et le travail déjà admis. Si le registre devient indisponible, il faut une décision préalable : fermer le chemin, employer une allocation d’urgence strictement bornée ou accepter un risque explicite. L’indisponibilité de l’observation ne doit pas produire silencieusement une permission.

Ce que les sources ne démontrent pas

Aucun service TLS, point terminal QUIC, VPN, nuage, base de données, appareil ou gestionnaire de clés n’a été testé. Un handshake réussi ne révèle pas l’autorité restante. Une étiquette valide prouve un contrôle cryptographique, pas la totalité du comptage passé. Un journal de rotation ne montre pas que tous les écrivains ont abandonné l’ancienne clé.

Le dossier n’établit ni incident, ni compromission, ni adoption, ni performance. Il fournit seulement un cadre plus exact pour demander les preuves manquantes.

Sources