Pourquoi AES-256 ne décrit pas une suite de chiffrement VPN

Demandez quel chiffrement utilise un VPN et la réponse arrive généralement en un mot : AES-256, ou ChaCha20, ou peut-être WireGuard. Cette réponse nomme un composant d’une couche, alors que ce qui protège réellement la connexion est un ensemble d’algorithmes remplissant quatre rôles différents. Confondre le composant avec l’agencement est l’erreur la plus courante dans ces discussions, et elle produit des comparaisons qu’on ne peut pas trancher.

Quatre tâches dans une connexion

Le chiffrement en masse transforme le texte clair en texte chiffré pour le canal de données, et sa clé est dérivée plutôt que transmise. La protection d’intégrité détecte une modification, ce qui est une tâche distincte même lorsqu’une seule construction fait les deux. L’établissement des clés produit le matériel de trafic partagé, et l’authentification du pair décide qui se trouve à l’autre bout. S’il en manque une, la connexion n’est pas sûre, quelle que soit la solidité de la pièce restante.

Certaines conceptions fusionnent deux rôles. AES-GCM et ChaCha20-Poly1305 sont des constructions de chiffrement authentifié, la confidentialité et l’intégrité arrivent donc ensemble ; AES-CBC non, et il exige un code d’authentification de message distinct avec sa propre clé. Lire une proposition comme un sac de nombres indépendants lit donc mal ceux qui ont été conçus par paires.

Les rôles se situent aussi à des couches différentes, et c’est pourquoi le même mot peut signifier des choses différentes dans deux produits. Un chiffrement par blocs dans ESP et un chiffrement par blocs dans TLS sont la même primitive dans des négociations différentes avec des exigences différentes. C’est pourquoi citer une primitive sans son mode et sa couche peut être pire que ne rien citer.

Pourquoi un nom de chiffrement ne dit presque rien

Prenez l’expression AES-256 au sérieux un instant : elle désigne un chiffrement par blocs et une taille de clé. Elle ne dit rien du mode d’opération, de la présence d’une intégrité, ni de la manière dont les clés ont été établies ou le pair authentifié. Deux produits peuvent tous deux annoncer AES-256 et différer sur tout le reste, y compris l’un qui l’associe à un mode non authentifié et l’autre qui utilise un mode AEAD avec un échange de clés moderne.

TLS 1.3 a porté cette séparation dans la norme, ce qui est une correction utile pour quiconque a appris le vocabulaire plus ancien. Ses suites de chiffrement ne nomment que l’AEAD et le hachage, tandis que les groupes d’échange de clés et les algorithmes de signature sont négociés comme des paramètres distincts. Un nom de suite TLS 1.3 n’est donc pas comparable à un nom de suite TLS 1.2 à conditions égales, même si les deux apparaissent dans le même champ d’un fichier de configuration. Un auditeur qui compare les deux chaînes directement tire une conclusion que le protocole n’étaye pas. Lisez aussi le groupe négocié et les paramètres de signature, sinon la comparaison reste incomplète.

WireGuard choisit la voie inverse et supprime la négociation presque entièrement : le protocole impose un ensemble d’algorithmes fixe, donc deux implémentations interopèrent ou non. C’est un choix de conception légitime, et cela signifie aussi que la question de la suite que négocie WireGuard n’a pas de réponse qui vaille une comparaison. Si vous l’auditez, lisez la spécification une fois puis auditez la gestion des clés autour plutôt que la négociation.

La couche décide du vocabulaire

Un déploiement IPsec négocie deux fois : une proposition IKE pour le canal de contrôle et une transformation ESP pour les données, et les deux peuvent légitimement différer. Lire la première et supposer qu’elle décrit la seconde est une source fréquente de confusion lors d’un audit, car le fichier de configuration mentionne les deux et l’intéressante est la seconde.

Un nom disponible dans une bibliothèque n’est pas automatiquement implémenté pour un autre chemin de données. C’est pourquoi l’affirmation selon laquelle notre produit prend en charge AES-256 est plus faible qu’elle n’en a l’air, et pourquoi un problème d’interopérabilité se résout généralement en trouvant l’intersection maintenue plutôt qu’en activant tous les algorithmes anciens des deux côtés.

La spécification TLS 1.3 est l’exemple publié le plus clair de la séparation, car elle définit la suite comme une paire et déplace le reste vers sa propre négociation. Une fois cette forme familière, la proposition IPsec et l’unique ensemble fixe de WireGuard se lisent comme des variantes de la même idée.

Lisez le résultat négocié, puis arrêtez

Une proposition configurée n’est pas la preuve de ce que deux pairs ont choisi. La session active porte la réponse, et toute implémentation courante peut la rapporter sans capture de paquets.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Dans la sortie, lisez les algorithmes sélectionnés plutôt que la liste proposée. Si la réponse est plus faible que la politique ne le voulait, la correction relève de la configuration de la proposition d’un côté ou de l’autre, et une divergence se manifeste dans les implémentations modernes comme une négociation échouée plutôt que comme une rétrogradation silencieuse.

Rappelez-vous ensuite ce que la suite ne couvre pas. Routes, autorisations applicatives, journalisation et rétention sont des décisions distinctes avec leur propre revue, et un agencement cryptographique compatible ne dit rien à leur sujet. La discussion sur le chiffrement vaut la peine, mais elle répond à une question plus étroite que celle que la plupart des gens posent réellement.

Gardez le vocabulaire précis et l’argument raccourcit. Une suite est un ensemble de rôles sur une couche, un chiffrement est un composant, et le résultat négocié est la seule chose qui décrive la connexion que vous avez réellement. Tout le reste dans la comparaison est décoration.