Votre navigateur est déjà passé au post-quantique : comment l'hybride X25519 et ML-KEM se déploie

Votre navigateur fait probablement de la cryptographie post-quantique depuis des mois, sans que vous ayez cliqué sur quoi que ce soit. Quand vous chargez une page avec une version récente de Chrome, Firefox ou Safari, il négocie une clé de session avec deux algorithmes à la fois : X25519, l’échange sur courbes elliptiques en qui vous avez confiance depuis des années, et ML-KEM, le schéma basé sur les réseaux normalisé par le NIST en 2024. Personne n’a publié de bannière. La bascule s’est faite, surtout pendant que vous lisiez autre chose.

Avant de lire : La menace « récolter maintenant, déchiffrer plus tard » et les nouvelles normes du NIST sont expliquées dans La bombe à retardement quantique : pourquoi les nouvelles normes de chiffrement du NIST n’attendront pas. Cet article regarde ce que ces normes donnent en production, et c’est plus désordonné et plus intéressant.

Table des matières

• Pourquoi jumeler deux algorithmes plutôt que choisir le meilleur
• La course au déploiement de 2024 et 2025
• Le paquet qui a fait sauter votre pare-feu
• Ce que l’hybride ne protège pas
• Sources

Pourquoi jumeler deux algorithmes plutôt que choisir le meilleur

La logique est celle d’une assurance dans les deux sens. Si un ordinateur quantique finit par briser X25519, ML-KEM protège toujours la session. Si ML-KEM cache une faille que personne n’a encore trouvée, X25519 tient toujours. Un attaquant doit battre les deux. Pensez à un coffre de banque qui exige deux clés différentes, détenues par deux personnes différentes. Ça compte, parce que ML-KEM est jeune : il a eu quelques années d’examen public, alors que X25519 en a eu plus de dix.

L’idée n’est pas nouvelle. En 2016, Google et Cloudflare ont mené une expérience appelée CECPQ1, qui combinait X25519 avec un schéma basé sur les réseaux nommé New Hope, et ils ont mesuré ce qui arrivait au vrai trafic. L’expérience a prouvé le concept, puis a dormi sur une tablette pendant que les organismes de normalisation finissaient leurs devoirs.

La course au déploiement de 2024 et 2025

Le calendrier a avancé plus vite que la plupart des gens l’attendaient. Chrome 124 a activé en avril 2024 un hybride appelé X25519Kyber768, puis est passé à la version finale X25519MLKEM768 avec Chrome 131 en novembre. Firefox a suivi plus tard en 2024. Au printemps 2025, Cloudflare rapportait qu’environ 38 % du trafic HTTPS humain qu’elle traitait utilisait un échange de clés post-quantique.

Du côté des serveurs et des systèmes, le retard a été comblé. OpenSSL 3.5 est sorti en avril 2025 avec ML-KEM et l’hybride intégrés. OpenSSH 10.0 a fait de mlkem768x25519-sha256 son échange de clés par défaut au même printemps. Apple a ajouté le TLS hybride post-quantique à iOS 26 et macOS 26. Signal était allé plus loin plus tôt, avec son protocole PQXDH livré en 2023, bien avant que la majorité du web ait entendu l’expression.

Le saviez-vous? L’identifiant TLS du groupe hybride X25519MLKEM768 est 0x11EC, soit 4588 en décimal. Un nombre bien banal pour une fonctionnalité qui va décider de la façon dont le web survit à la prochaine décennie.

Le paquet qui a fait sauter votre pare-feu

Voici la partie qui ne se retrouve jamais dans le communiqué. Le partage de clé hybride du client fait 1 216 octets : 1 184 pour la clé publique ML-KEM-768 et 32 pour X25519. Ajoutez le reste d’un ClientHello moderne, et le premier message d’une négociation TLS s’étire maintenant sur plusieurs segments TCP au lieu de tenir dans un seul.

Le saviez-vous? Un ClientHello standard tenait confortablement dans une seule trame Ethernet de 1 500 octets. Le partage hybride à lui seul mange maintenant la majeure partie de ce budget.

Ça semble anodin jusqu’à ce qu’on se souvienne de qui se trouve au milieu du réseau. Les pare-feu d’entreprise, les vieux équilibreurs de charge et les appareils d’inspection profonde de paquets ont été écrits en supposant qu’un ClientHello est petit et arrive d’un seul bloc. Certains laissent tomber, réinitialisent ou abîment en silence ce qu’ils ne comprennent pas. Chaque réseau d’entreprise a un appareil que personne n’a redémarré depuis l’administration Obama, et c’est lui qui décide maintenant si votre défense quantique fonctionne vraiment.

C’est pour ça que le déploiement ressemble à un escalier : on livre, on mesure la casse, on revient en arrière, on corrige, on livre encore. Les navigateurs et les serveurs ont géré le problème en refaisant la négociation avec un échange classique quand l’hybride échouait. Ça garde le web fonctionnel, mais ça veut aussi dire qu’un attaquant capable de bloquer le gros paquet peut, en principe, forcer ce repli.

Ce que l’hybride ne protège pas

C’est là que je trouve que le marketing dépasse les mathématiques. L’échange de clés hybride protège la confidentialité des sessions enregistrées aujourd’hui. Il ne fait rien pour les certificats qui authentifient le serveur. Ceux-ci reposent encore sur les signatures RSA et ECDSA, qu’un futur ordinateur quantique pourrait forger. La menace sur les certificats concerne l’usurpation au moment où l’attaquant dispose de la machine, pas les données déjà aspirées. L’échéance est donc différente, et probablement plus tardive.

Mon avis honnête : livrer l’échange de clés hybride était la bonne décision, et les équipes des navigateurs méritent du crédit de l’avoir fait avant qu’on les y oblige. Mais « sécurisé contre le quantique » sur une page de présentation d’un fournisseur décrit une clé de session, pas toute la pile. La migration des signatures post-quantiques est le vrai gros morceau, et elle vient à peine de commencer.

Sources

• NIST FIPS 203 (ML-KEM), août 2024
• IETF draft-ietf-tls-ecdhe-mlkem (groupe hybride X25519MLKEM768 pour TLS 1.3)
• Blogue de Google Chrome et notes de version de Chrome 124 et Chrome 131 (2024)
• Blogue de Cloudflare et statistiques d’adoption post-quantique de Cloudflare Radar (2025)
• Adam Langley, description de l’expérience CECPQ1 (2016)
• Annonce de sortie d’OpenSSL 3.5 (2025)
• Notes de version d’OpenSSH 10.0 (2025)
• Annonces Apple WWDC25 (iOS 26, macOS 26)
• Blogue de Signal : spécification PQXDH (2023)