WireGuard est-il sûr face au post-quantique ? Ce que le protocole fournit réellement

La question revient chaque fois que l'informatique quantique fait l'actualité : mon VPN me protège-t-il encore ? Pour WireGuard, la réponse honnête suppose de séparer ce que le protocole fait aujourd'hui de ce qu'un organisme de normalisation a publié, car ce ne sont pas la même chose.

La partie réellement vulnérable

La poignée de main de WireGuard repose sur Curve25519. L'échange de clés sur courbe elliptique est exactement la famille de cryptographie qu'un grand ordinateur quantique casserait, et c'est précisément pour cela que la question se pose.

Ce n'est pas un défaut de WireGuard. C'est l'état de presque tous les échanges de clés déployés, et c'est pourquoi le NIST a mené un processus pluriannuel pour en normaliser des remplaçants.

Ce que le NIST a réellement normalisé

Le 13 août 2024, le NIST a publié FIPS 203, qui spécifie un mécanisme d'encapsulation de clé appelé ML-KEM.

Un KEM fait une seule chose précise : il permet à deux parties d'établir une clé secrète partagée sur un canal public, laquelle peut ensuite servir au chiffrement et à l'authentification symétriques ordinaires. Sa sécurité repose sur le problème Module Learning with Errors et, dans la formulation prudente de la norme, elle est réputée sûre, même face à des adversaires qui possèdent un ordinateur quantique.

La norme définit trois jeux de paramètres, ML-KEM-512, ML-KEM-768 et ML-KEM-1024, par force de sécurité croissante et performance décroissante. Notez la formulation d'un bout à l'autre : réputée sûre. C'est ainsi que les cryptographes écrivent, et cela mérite d'être lu au pied de la lettre plutôt que comme une précaution marketing.

Ce que WireGuard propose à la place

WireGuard n'implémente pas ML-KEM. Ce que décrit sa page de protocole, c'est une clé pré-partagée optionnelle, à utiliser si une couche supplémentaire de cryptographie à clé symétrique est requise (pour, disons, une résistance post-quantique).

Trois détails comptent ici.

Elle est mélangée, pas substituée. La clé pré-partagée est combinée à la cryptographie à clé publique pendant la dérivation de clé. Un attaquant doit donc à la fois casser Curve25519 et détenir le secret partagé. La courbe elliptique n'est pas retirée, elle est doublée.

Elle est désactivée par défaut. Quand le mode clé pré-partagée n'est pas utilisé, la valeur est traitée comme une chaîne de 32 octets entièrement à zéro. Rien ne se produit tant que vous ne la configurez pas.

La documentation elle-même use d'une précaution. La formule est pour, disons, une résistance post-quantique. Ce « disons » fait un vrai travail : la page propose le cas d'usage comme un exemple plutôt que comme une garantie, et n'énonce aucune affirmation formelle de sécurité face aux adversaires quantiques. Un protocole qui voudrait afficher une sûreté post-quantique ne le formulerait pas ainsi.

La distinction qui décide de tout

Les deux approches aboutissent à un secret partagé, mais elles résolvent les deux moitiés opposées du problème.

ML-KEM établit un secret entre des parties qui ne se sont jamais rencontrées, sur un canal que n'importe qui peut observer. C'est le problème difficile, et c'est celui que menace un ordinateur quantique.

La clé pré-partagée de WireGuard suppose que le secret existe déjà. Vous devez acheminer 32 octets vers les deux pairs par un autre chemin, en toute sécurité, et les protéger ensuite.

La clé pré-partagée est donc une atténuation réelle, et ce n'est pas la même chose qu'un établissement de clé post-quantique. Si vous pouvez distribuer des secrets hors bande, cela fonctionne. Si vous ne le pouvez pas, cela n'aide pas, et l'activer autant que vous voulez n'y changera rien.

Ce qu'il faut faire concrètement

Activez-la si vous contrôlez les deux extrémités. Tunnels site à site, vos propres serveurs, une poignée d'appareils que vous administrez : le problème de distribution de clés est réduit et l'atténuation est réelle. Elle répond à la question du récolter maintenant, déchiffrer plus tard, où le trafic capté aujourd'hui est stocké jusqu'à l'existence d'un ordinateur quantique.

Pesez honnêtement le coût opérationnel. Chaque paire de pairs a besoin de sa propre clé, distribuée en toute sécurité, renouvelée et protégée. Une clé pré-partagée qui fuit est pire que pas de clé, car elle supprime la couche que vous pensiez avoir pendant que vous continuez à croire qu'elle est là.

Ne vous attendez pas à ce que votre VPN commercial la propose. Le modèle de la clé pré-partagée convient à une infrastructure que vous possédez, pas à un fournisseur qui sert des milliers de clients. Si un fournisseur revendique une protection post-quantique, la question utile est : quel mécanisme, et s'agit-il de ML-KEM ou de quelque chose qu'il a lui-même baptisé.

Le résumé honnête

WireGuard n'est pas post-quantique par défaut, et sa poignée de main repose sur Curve25519, que l'informatique quantique menace directement.

Sa réponse est une clé pré-partagée optionnelle, mélangée à la cryptographie existante, désactivée sauf configuration, et décrite par sa propre documentation avec un disons délibéré plutôt qu'avec une promesse. ML-KEM du NIST, normalisé dans FIPS 203 le 13 août 2024 avec trois jeux de paramètres, résout le problème plus difficile : établir un secret en premier lieu.

Utilisez la clé pré-partagée là où vous pouvez distribuer les clés en toute sécurité. Ne la confondez pas avec la norme, et méfiez-vous de quiconque brouille les deux.

La description de ML-KEM, la date de publication de FIPS 203 du 13 août 2024, les trois jeux de paramètres, la base Module Learning with Errors et la formule sur la sécurité réputée face à des adversaires qui possèdent un ordinateur quantique proviennent de la page publiée par le NIST pour FIPS 203. La clé pré-partagée optionnelle, sa finalité annoncée, son mélange à la cryptographie à clé publique et la valeur par défaut de 32 octets entièrement à zéro proviennent de la documentation du protocole WireGuard. Les deux ont été vérifiées au moment de la rédaction. Les liens commerciaux portent l'attribut rel="sponsored nofollow" ; une commission d'affiliation peut s'appliquer sans surcoût pour vous.