Pourquoi un paquet VPN chiffré peut coûter moins que vous ne le pensez

Deux profils sont mesurés sur la même passerelle, l’un avec chiffrement et l’autre sans, et le chiffré n’est pas plus lent. Il est parfois plus rapide, ce qui déclenche généralement une longue discussion sur la question de savoir si le test a été exécuté correctement. Le résultat est plausible, car le coût d’un paquet n’est pas le nombre de mots cryptographiques dans la configuration. C’est l’ensemble des opérations que l’implémentation effectue, sur le matériel dont elle dispose, selon la disposition de tampon qu’elle a choisie.

Le symptôme : ce n’est pas le profil chiffré qui est lent

Supposons qu’un test historique compare un chiffrement AEAD à un mode « sans chiffrement » qui calcule encore un code d’authentification distinct par paquet. Le second profil masque le contenu de la charge utile mais conserve un hachage par paquet, et sur un processeur sans accélération pour ce hachage, il peut coûter plus cher que la construction intégrée qu’il devait battre.

L’étiquette dans la configuration dit « chiffrement », et l’étiquette est tout ce que regardent la plupart des comparaisons. Le chemin du paquet dit autre chose : un profil effectue une opération combinée pour laquelle le processeur dispose d’instructions, et l’autre une opération séparée pour laquelle il n’en a pas. Lire le seul fichier de configuration ne révélera jamais cette différence, car les deux entrées ressemblent à une seule ligne. Seuls le mode négocié et le chemin de code derrière lui expliquent le résultat.

C’est toute l’explication, et elle n’exige aucune affirmation sur la primitive qui serait universellement plus rapide. Les deux peuvent être rapides, les deux peuvent être lentes, et l’ordre dépend de la machine et du code.

Comptez les opérations, pas les étiquettes

Une construction AEAD, telle que la décrit la RFC 5116, donne à l’implémentation une interface unique qui renvoie le texte chiffré et l’étiquette ensemble. AES-GCM en est un exemple : chiffrement en mode compteur combiné à un authentificateur de Galois. L’interface ne rend pas l’intégrité gratuite ; elle rend la combinaison bien définie, et c’est ce qui permet à une implémentation d’optimiser la paire comme une unité.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

Ce sont des esquisses de traitement, pas des conseils de configuration. La première n’offre aucune confidentialité mais dépense quand même du processeur en authentification, et c’est précisément pourquoi « désactiver le chiffrement » n’est pas synonyme de « désactiver le travail cryptographique ».

La seconde peut être moins coûteuse parce que les processeurs fournissent des instructions pour les deux moitiés : les tours AES et la multiplication sans retenue qu’utilise le corps de Galois. Les bibliothèques traitent aussi des tampons indépendants en parallèle, ce qui maintient ces instructions occupées au lieu d’attendre la mémoire.

Ce que le mode négocié permet réellement

Avec Community OpenVPN, un chiffrement de données AEAD signifie que l’option auth ne fournit plus son propre HMAC distinct pour le canal de données. La référence de l’option de chiffrement décrit cette portée, et c’est la raison pour laquelle deux configurations qui se ressemblent dans un fichier texte peuvent différer par le travail par paquet.

Lisez le mode négocié plutôt que la liste de souhaits. Une liste de chiffrements autorisés et un nom de suite TLS ne vous disent pas quelles opérations s’exécutent sur la charge utile, et une ancienne ligne cipher peut ne pas décrire ce que la connexion actuelle a choisi.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

La première commande liste les chiffrements pris en charge par le binaire, ce qui est une liste de capacités et non le résultat négocié. La seconde montre ce que le serveur demande réellement. Le journal de connexion est l’endroit où confirmer le choix final, car un client peut retomber sur quelque chose que le serveur autorise mais que personne n’avait prévu.

Mesurez la charge de travail que vous exécutez vraiment

Un microbenchmark cryptographique mesure une primitive dans ses propres conditions. Un transfert VPN copie aussi des tampons, planifie des threads ou des interruptions, vérifie des politiques et traverse le réseau. Ces parties dominent souvent, et c’est pourquoi une primitive plus rapide ne produit pas toujours un tunnel plus rapide.

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

Ces deux commandes vous donnent une comparaison locale approximative des primitives sur la machine devant vous, et elles sont honnêtes sur le fait d’être des microbenchmarks. Elles ne disent rien du débit de votre tunnel, et elles ne devraient jamais être citées comme tel.

Mesurez ensuite la charge qui compte, en gardant tout le reste constant : même point de terminaison, mêmes tailles de paquet, même transport, même politique de compression. Si le changement de profil a aussi modifié le transport ou l’emplacement de traitement, le résultat décrit ce lot et non la cryptographie.

Gardez aussi l’objectif en vue. Un chemin de données disposant de capacité cryptographique en réserve peut encore être limité par la latence parce que l’application attend des allers-retours, et des gains de capacité brute ne corrigent pas un protocole bavard. Mesurez la configuration prise en charge et approuvée par la politique dans son ensemble, et traitez « moins de boîtes doit être plus rapide » comme l’hypothèse qu’elle est. La question utile n’est pas de savoir si le chiffrement coûte quelque chose, mais si le coût apparaît dans la mesure qui vous importe vraiment.