Combien coûte le web post-quantique
Combien coûte le web post-quantique
Les migrations cryptographiques peuvent être difficiles, mais des protocoles bien conçus, bâtis autour de la «crypto-agility», rendent la transition indolore. Beaucoup d’utilisateurs n’ont peut-être même pas remarqué que chaque grand navigateur propose désormais un échange de clés quantique-sûr pour chaque connexion HTTPS, alors que seule la moitié du million de premiers sites web l’accepte.
Dans notre article précédent, nous avons expliqué pourquoi les attaques «harvest-now-decrypt-later» (HNDL) placent l’échange de clés en première ligne de la cryptographie post-quantique. Le trafic enregistré aujourd’hui pourra être déchiffré dès qu’un ordinateur quantique cryptographiquement pertinent existera, si bien que les données qui doivent rester secrètes pendant des années sont déjà exposées. TLS sécurise presque tout ce qui circule en ligne, et c’est l’un des premiers protocoles à passer post-quantique à grande échelle. C’est l’une des plus grandes migrations cryptographiques en cours, et la meilleure preuve de production dont nous disposions de ce que coûte la cryptographie post-quantique.
Où se situe le risque quantique dans TLS
TLS offre différentes protections pour le trafic web. Il authentifie les parties, prouvant que le site que vous ouvrez provient bien de votre banque, et il chiffre le trafic, de sorte que votre fournisseur d’accès ne voie pas le mot de passe que vous saisissez. Cet article porte sur le chiffrement. L’authentification et la prochaine évolution de X.509 vers Merkle Tree Certificates (MTCs) seront traitées dans un futur article.
Le chiffrement TLS fonctionne en deux étapes. Le client et le serveur conviennent d’abord d’un secret partagé, puis l’utilisent pour tout chiffrer avec un chiffrement symétrique comme AES. Le chiffrement symétrique est déjà sûr face aux attaques quantiques. L’échange de clés ne l’est pas. C’est précisément ce que casse un ordinateur quantique.
Nous nous sommes concentrés sur TLS 1.3, la seule version dotée d’un échange de clés quantique-sûr. Le client démarre avec un ClientHello qui propose plusieurs algorithmes d’échange de clés et joint sa moitié de l’échange pour chacun. Le serveur en choisit un, calcule sa propre moitié et la renvoie dans un ServerHello. Cette conception rend TLS agile sur le plan cryptographique. Un serveur peut ajouter un échange de clés post-quantique sans casser les anciens clients. Il retient l’option post-quantique lorsqu’un client moderne la propose, et retombe sur l’option classique pour les anciens clients.
Un échange de clés hybride
L’échange de clés TLS a fonctionné pendant des années presque exclusivement sur Diffie-Hellman à courbes elliptiques avec X25519. C’est rapide, ses «key shares» sont minuscules, mais ce n’est pas post-quantique-sûr. Son remplaçant est X25519MLKEM768, une construction hybride qui conserve X25519 et fait tourner ML-KEM à ses côtés, le standard post-quantique d’encapsulation de clés publié par le NIST en 2024.
X25519 et ML-KEM produisent chacun un secret partagé, et TLS combine les deux. L’échange de clés reste sûr tant que l’un des deux tient. Un ordinateur quantique cassant X25519 ne suffit pas, et une faille future dans ML-KEM non plus. Ce filet de sécurité ne coûte presque rien en calcul. Le prix se paie en taille, avec des «key shares» plus de trente fois plus grandes :
Tous les navigateurs modernes prennent désormais en charge cet échange de clés. Firefox 132 a activé X25519MLKEM768 par défaut en octobre 2024, et Chrome 131 a suivi en novembre 2024. Edge, Brave et Opera en héritent via Chromium, et Apple l’a activé dans Safari avec iOS 26 et macOS 26 en septembre 2025. En septembre 2026, Cloudflare Radar indique qu’environ les trois quarts du trafic web suisse vers Cloudflare proviennent de clients qui demandent un échange de clés post-quantique.
Les serveurs n’ont pas suivi. Dans le «crawl» de septembre 2026 de Jan Schaumann, seule la moitié du million de premiers sites web prenait en charge un échange de clés post-quantique. Si vous hébergez vos propres sites web, la plupart de vos visiteurs demandent déjà un échange de clés quantique-sûr. S’ils en obtiennent un dépend de votre configuration «edge».
Ce que cela coûte
Nous avons mesuré de vrais «handshakes» contre un endpoint HTTPS réel sur TCP et QUIC, les deux transports qui portent HTTPS aujourd’hui. Client, serveur et chemin réseau sont restés identiques. Nous n’avons basculé que le groupe post-quantique de chaque côté, ce qui donne quatre configurations. Les tailles indiquées comprennent tout jusqu’aux premières données applicatives, y compris les octets du handshake TCP le cas échéant :
- Classique. Aucune des deux parties ne propose le groupe hybride.
- Client seul. Le client propose le groupe hybride et le serveur ne le prend pas en charge.
- Serveur seul. L’inverse.
- Les deux PQC. Les deux parties prennent en charge X25519MLKEM768.
Taille du «handshake» sur le fil
Les octets sont là où la PQC coûte quelque chose. La PQC complète fait grossir le handshake de 2,6 Ko sur les deux transports, de 3,3 Ko à 5,9 Ko sur TCP et de 4,4 Ko à 7,0 Ko sur QUIC. Presque tout se trouve dans les deux messages Hello, environ 1,2 Ko dans le ClientHello et 1,1 Ko dans le ServerHello. Les handshakes QUIC sont environ 1 Ko plus grands que ceux de TCP dans chaque configuration, avec ou sans PQC. QUIC économise quelques octets grâce aux en-têtes UDP plus légers, mais en perd davantage parce qu’il bourre les paquets Initial du client jusqu’à 1 200 octets pour prévenir les attaques par amplification DDoS. Les clients appliquent aussi GREASE, randomisant le ClientHello pour empêcher les «middleboxes» de supposer des octets fixes, de sorte que les tailles exactes varient légèrement d’une connexion à l’autre.
Quand une seule partie prend en charge la PQC, le coût n’est pas symétrique. Un client qui propose la PQC à un serveur classique envoie quand même sa «key share» de 1,2 Ko pour rien, tandis qu’un serveur avec PQC activé n’ajoute pas un seul octet pour les clients classiques. La plupart de vos visiteurs paient déjà ce péage à chaque connexion sans en retirer aucune protection. Activer la PQC sur votre serveur ne coûte rien aux clients classiques et transforme les octets qu’ils envoient déjà en protection réelle.
Mettez ces kilooctets en regard du reste de la connexion. Nous avons enregistré un après-midi de navigation normale et divisé le trafic total par le nombre de handshakes. Notre après-midi de navigation a produit environ 70 Ko par handshake en moyenne. Le surcoût post-quantique représente donc moins de 4 % du trafic.
Durée du «handshake»
Durée du «handshake» TLS sur une connexion propre
Sur une connexion propre, l’échange de clés quantique-sûr est presque gratuit. La PQC complète ajoute 0,4 ms sur TCP et 0,9 ms sur QUIC, moins que la dispersion d’environ 1,5 ms entre les exécutions. Quand une seule partie prend en charge le groupe hybride, les deux se rabattent sur X25519 et le handshake coûte autant qu’avant. Le temps CPU ne bouge pas non plus, côté client comme côté serveur. ML-KEM s’exécute en dizaines de microsecondes, à peu près aussi vite que X25519. Le vrai écart se trouve entre les transports. QUIC termine en environ 23 ms contre 44 ms pour TCP, parce qu’il mène le handshake de transport et le handshake TLS ensemble et économise un aller-retour complet. TCP doit terminer son propre handshake avant même que TLS ne puisse commencer.
Durée du «handshake» TLS sur Wi-Fi dégradé
La différence est plus visible sur un mauvais réseau. Nous avons rejoué les mêmes exécutions sur une connexion Wi-Fi dégradée simulée, ce qui double à peu près chaque handshake. La PQC complète ajoute alors 6,4 ms sur TCP (+8 %) et 7,0 ms sur QUIC (+16 %). Le coût vient des paquets, pas du calcul. Les Hellos plus grands font passer un handshake TCP de 10 à 14 paquets, et un handshake QUIC de 6 à environ 9. Chaque paquet supplémentaire donne à la latence et aux pertes une chance de plus de bloquer le handshake. Même un client PQC face à un serveur classique perd 4,3 ms sur QUIC, parce que son ClientHello plus grand traverse le réseau, quel que soit le choix du serveur.
L’authentification reste classique
L’échange de clés hybride comble la lacune HNDL. Il ne protège pas l’authentification, qui repose toujours sur des signatures classiques qu’un ordinateur quantique pourra un jour falsifier. La différence tient au calendrier. Un handshake enregistré peut être déchiffré des années plus tard, alors qu’une signature ne peut être falsifiée que sur une connexion en cours. C’est pourquoi l’échange de clés est passé en premier.
Merkle Tree Certificates (MTCs), issus du groupe de travail PLANTS de l’IETF, s’attaquent à la taille des signatures post-quantiques. Google et Cloudflare achèvent une expérience en conditions réelles qui a prouvé que l’approche fonctionne, et la production suivra. Let’s Encrypt prévoit d’émettre des MTCs en 2027, et Cloudflare lance sa propre autorité de certification publique pour le faire dès début 2027. Nous traiterons les MTCs et l’avenir du Web PKI dans un article dédié. D’ici leur arrivée en production, l’échange de clés est la moitié que vous contrôlez.
