Le «harvest-now-decrypt-later» fait tomber cette hypothèse. Vu de l’extérieur, un tunnel VPN n’est qu’un flux de paquets chiffrés, et n’importe qui sur le trajet peut l’enregistrer dès aujourd’hui. Le jour où un ordinateur quantique cryptographiquement pertinent casse l’échange de clés du tunnel, tout son contenu devient lisible, y compris les protocoles internes qui comptaient sur lui pour rester confidentiels. Comme un seul échange de clés protège tout le trafic entre deux réseaux, le VPN est une cible de choix pour qui enregistre aujourd’hui et déchiffre demain.

Pour ce troisième protocole de la série, nous nous intéressons à WireGuard, devenu la référence moderne, et mesurons ce qu’il en coûte de le rendre résistant au quantique.

Contrairement à TLS et SSH, WireGuard n’est pas crypto-agile, et c’est voulu. Pas de négociation d’algorithmes, un seul jeu de primitives, toujours le même. Son handshake reste ainsi très compact, mais impossible d’y ajouter ML-KEM sans modifier le protocole. Pour devenir post-quantique, WireGuard doit passer par la seule porte que ses concepteurs ont laissée ouverte, une clé pré-partagée optionnelle :

Cette clé symétrique de 32 octets est utilisée dans chaque handshake, et le whitepaper de WireGuard la présente explicitement comme une protection contre de futures attaques quantiques. Sans elle, un attaquant qui casse X25519 n’obtient pas les clés de session. Et si elle fuite, la connexion reste aussi sûre qu’un WireGuard classique. On retrouve le même principe hybride que pour TLS et SSH.

Seul problème : une clé statique écrite dans un fichier de configuration se distribue et se renouvelle à la main, et ne change jamais toute seule. Pour bien faire, il faut en générer régulièrement une nouvelle grâce à un échange de clés post-quantique qui tourne à côté de WireGuard.

Rosenpass combine deux mécanismes post-quantiques. Chaque extrémité possède une clé Classic McEliece statique, et chaque handshake y ajoute un échange ML-KEM avec une clé éphémère, générée pour l’occasion. McEliece et ML-KEM contribuent tous deux à la clé finale.

Rosenpass utilise McEliece pour les clés statiques parce que ses chiffrés sont petits : 188 octets, contre 768 pour ML-KEM. Ses clés publiques sont en revanche énormes, environ 512 Ko. Mais comme les clés WireGuard, elles ne s’échangent qu’une fois, hors bande, et ne transitent jamais sur le réseau pendant un handshake.

En septembre 2026, le BSI allemand a toutefois déconseillé Classic McEliece pour les nouveaux développements, à la suite d’attaques récentes, pas encore exploitables en pratique. Comme Rosenpass utilise aussi ML-KEM, les échanges enregistrés restent protégés. Seule l’authentification serait concernée.

D’autres produits font le même choix McEliece + ML-KEM : Mullvad VPN s’en sert pour dériver sa clé pré-partagée WireGuard, et NetBird intègre directement Rosenpass.

Contrairement à nos articles précédents, il n’y a cette fois que deux configurations possibles : WireGuard seul des deux côtés, ou WireGuard avec Rosenpass des deux côtés. Rosenpass étant un protocole à part entière, les deux extrémités doivent basculer en même temps.

Avec Rosenpass, le handshake passe de 324 octets à 3,0 Ko, soit 2,6 Ko de plus. Celui de WireGuard reste à 324 octets. Tout le surcoût vient donc de Rosenpass, et surtout de ML-KEM.

Rosenpass a besoin de deux allers-retours réseau, ce qui ajoute 49 ms sur un bon réseau et 70 ms sur un Wi-Fi dégradé. Le handshake de WireGuard, lui, ne change pas. Sur Wi-Fi, il prend simplement plus de temps, car le réseau y est plus lent.

Dans notre lab, les deux handshakes se suivent. En pratique, rien ne l’impose : WireGuard ne sait rien de Rosenpass et utilise simplement la dernière clé reçue lors de son handshake suivant.

Sur un tunnel utilisé, c’est insignifiant. Appliqué à un après-midi de travail sur notre propre VPN WireGuard, Rosenpass aurait ajouté 0,13 % au trafic, contre 0,02 % pour les handshakes de WireGuard.

OpenVPN négocie ses clés dans un handshake TLS : le rendre post-quantique revient à rendre TLS post-quantique. Avec OpenSSL 3.5 ou plus récent, il peut négocier le même échange de clés hybride X25519MLKEM768 que les navigateurs. Le coût est celui mesuré dans notre article sur TLS : quelques kilo-octets par handshake, sans délai perceptible.

Pour l’authentification, c’est une autre affaire. OpenVPN authentifie en général le serveur et le client par des certificats X.509, et le passage à ML-DSA rend chaque certificat et chaque signature plusieurs fois plus lourds.

IPsec adopte lui aussi l’approche hybride pour l’échange de clés. Les deux côtés peuvent enchaîner des échanges de clés supplémentaires après l’échange classique, et l’IETF est en train de standardiser ML-KEM comme échange post-quantique. Côté authentification, IPsec utilise soit des certificats, qui posent la même question de taille avec ML-DSA qu’OpenVPN, soit des clés pré-partagées, dont l’échange sécurisé revient alors à l’administrateur.

Son principal défaut : il ne s’arrête jamais. Rosenpass renouvelle la clé toutes les deux minutes, même quand le tunnel ne sert pas. Un mode «lazy», qui ne la renouvellerait que lorsque du trafic circule, comme WireGuard, supprimerait l’essentiel de ce coût. Nous ignorons si l’équipe de Rosenpass en prévoit un, et il aurait un prix. À la reprise du trafic, WireGuard devrait soit attendre une nouvelle clé, et les premiers paquets subiraient les allers-retours de Rosenpass, soit repartir avec une clé plus ancienne.

Planifiez dès maintenant la migration de vos VPN vers la cryptographie post-quantique, et protégez aussi les services internes indépendamment du tunnel. Tout commence par un inventaire cryptographique : quels tunnels reposent encore sur un échange de clés classique, et quels services internes comptent sur eux pour leur confidentialité.