AEAD apporte l’intégrité, pas une connexion ni une route qui fonctionne

Le chiffrement authentifié renvoie deux choses à la fois : un texte chiffré qui cache le contenu, et une étiquette qui permet au destinataire de détecter une falsification. Auparavant, ces fonctions étaient assemblées à partir de pièces séparées, et les mauvaises combinaisons produisaient des défaillances subtiles. Les constructions modernes fixent la combinaison et les conditions dans lesquelles elle tient. Le mot authentifié renvoie ici à l’étiquette, non à une personne.

Les deux garanties portent sur le paquet protégé et sur rien en dehors.

Deux garanties dans une construction

Le chiffrement répond à la question de savoir si un observateur peut lire ceci ; l’intégrité répond à celle de savoir si cela a été modifié. Un tunnel a besoin des deux, car un contenu modifié est pire qu’un contenu illisible. AEAD définit comment les combiner sous une clé, avec des données associées qui sont authentifiées mais non chiffrées. Le destinataire rejette une entrée qui échoue au contrôle.

Les données associées lient les champs visibles au contrôle. Lesquels dépendent du protocole, et ce n’est pas la promesse que toute adresse extérieure soit devenue secrète : un champ peut être couvert par l’étiquette et rester lisible sur le réseau.

Le nonce n’est pas un détail

Les clés et les nonce doivent être manipulés correctement, et la réutilisation d’un nonce échoue brutalement. Répéter un nonce sous une clé peut révéler des relations entre messages et ruiner entièrement la garantie d’intégrité. C’est pourquoi le protocole, et non l’application, gère la génération et l’ordre des nonce.

C’est une condition de la garantie, pas une suggestion d’implémentation. Des nonce négligés ne fournissent pas la propriété annoncée.

La protection contre le rejeu est un état séparé

Un ancien paquet valide peut être rejoué alors que son étiquette reste intacte, car l’étiquette prouve l’authenticité et non la fraîcheur. Traiter le rejeu demande son propre état : des numéros de séquence, une fenêtre et une règle sur ce qu’on accepte. Cet état vit dans l’implémentation du protocole et n’a rien à voir avec le choix du chiffrement. Un tunnel au chiffrement fort mais sans protection contre le rejeu accepte encore le trafic d’hier.

Les deux mécanismes coopèrent sans être le même, et l’un peut être correct alors que l’autre manque.

Ce que l’étiquette ne vous dit pas

L’identité du pair est établie par des certificats ou des clés pré-partagées, non par le fait qu’un chiffrement soit authentifié. Le routage, la résolution de noms et la politique de journalisation de l’opérateur se situent hors de la frontière cryptographique. Une négociation d’algorithme réussie dit seulement que les deux extrémités se sont accordées sur une suite, cela parle de compatibilité, pas de la qualité de l’implémentation de chaque côté.

Pour les utilisateurs : choisissez une configuration de protocole maintenue et prise en charge. AEAD est une propriété de cette configuration, pas une invitation à construire du chiffrement à la main autour d’un tunnel.

Notez quelle suite a été négociée, si la protection contre le rejeu est active et comment les pairs sont identifiés. Trois faits, trois garanties différentes.