Pourquoi un plus grand nombre de clé ne rend pas un VPN plus sûr

La publicité annonce 256 bits, l'autre produit annonce 128 bits, et la conclusion paraît évidente jusqu'à ce qu'on remarque que ces nombres décrivent des choses différentes. Une clé de chiffrement symétrique, une clé publique de certificat et un paramètre d'échange de clés ne se mesurent pas sur une même échelle. Aucune d'elles ne couvre le fait que le client ait vérifié le serveur, ou non. Le nombre est une information réelle, et elle est bien plus étroite que le marketing qui l'entoure ne le laisse croire.

Demandez quelle clé est comptée et ce qu'elle protège avant de comparer quoi que ce soit.

Trois clés, trois rôles

Le chiffrement des données chiffre la charge utile du tunnel, et sa clé est dérivée à nouveau pour la session. La clé publique du certificat prouve l'identité d'un point de terminaison lors de l'authentification. L'étape d'échange de clés, généralement une variante éphémère de Diffie-Hellman, établit un secret partagé qu'aucun des deux côtés ne peut reconstruire ensuite. Chacune a ses propres hypothèses de robustesse et ses propres conventions de taille.

C'est pourquoi un 256 à côté d'un 2048 à côté d'un 32 ne peuvent pas être classés par grandeur ; ce sont des réponses à des questions différentes.

Même à l'intérieur d'un seul rôle, le nombre ne dit quelque chose que par rapport à la famille d'algorithmes utilisée.

Où le nombre aide, et où il s'arrête

Au sein d'un algorithme, une clé plus grande augmente le coût d'une recherche par force brute, et les recommandations publiées fixent des minimums pour les clés de certificat à mesure que la puissance de calcul évolue. C'est une comparaison légitime et étroite : AES-128 et AES-256 résistent tous deux à une attaque directe avec de larges marges, si bien que la différence est rarement le facteur décisif en pratique.

En dehors de cette comparaison, le nombre ne prédit rien sur les erreurs de configuration, la validation des certificats ou la version du protocole.

Lire toute la suite négociée

Ce qu'une connexion utilise réellement est une suite : un mode de chiffrement, une construction d'intégrité ou de chiffrement authentifié, un groupe d'échange de clés et une méthode d'authentification. Un mode AEAD moderne avec une poignée de main correcte est une autre proposition qu'un mode plus ancien associé à un MAC séparé, même lorsque la taille de clé annoncée est identique.

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

Lisez le résultat négocié plutôt que le maximum configuré. Un client qui propose une suite forte se connecte tout de même faiblement si le serveur choisit l'option la plus faible et que le profil l'autorise. Si la performance est la préoccupation, mesurez-la sur l'appareil et le chemin concernés, car la taille de clé prédit mal le débit dès que l'accélération matérielle et la taille des paquets entrent en jeu.

Les parties qu'aucun nombre ne mesure

La maintenance logicielle est la première omission. Un tunnel bâti sur une bibliothèque qui ne reçoit plus de correctifs est plus faible que sa taille de clé ne le suggère, et aucune valeur de configuration n'y remédie. Le comportement de l'opérateur est la deuxième : les journaux de connexion, les données de compte et le traitement du support se situent entièrement hors de la cryptographie. Un service qui conserve plus que prévu ne devient pas plus sûr avec une clé plus longue.

La vérification du pair est la troisième et la plus lourde de conséquences. Un client qui accepte n'importe quel certificat a un chiffrement fort enveloppé autour d'un pair non authentifié, ce qui est pire qu'un chiffrement modeste avec une validation correcte. Vérifiez ces trois points avant le nombre, et le nombre reprendra sa juste place.