État des lieux de l'Internet post-quantique en 2025

Cette semaine, la dernière d'octobre 2025, nous avons franchi une étape importante concernant la sécurité d'Internet : la majorité du trafic d'origine humaine destiné à Cloudflare utilise le chiffrement post-quantique pour atténuer les menaces suivant l'approche collecter maintenant/déchiffrer plus tard.

Nous souhaitons profiter de ce moment de joie pour faire le point sur l'état actuel du processus de migration d'Internet vers le chiffrement post-quantique (PQC, Post-Quantum Cryptography) et sur le long chemin qui reste encore à parcourir. Notre dernière vue d'ensemble remonte à 21 mois et l'actualité s'est révélée particulièrement chargée depuis. Une grande partie des événements que nous avions prédits se sont réalisés : finalisation des normes NIST, adoption généralisée du chiffrement post-quantique, roadmaps plus détaillées de la part des organismes de réglementation, progrès dans la mise au point des ordinateurs quantiques, compromission d'une partie des algorithmes de chiffrement (pas d'inquiétude : rien de comparable à l'offre déployée) et avènement de nouveaux développements passionnants dans le domaine du chiffrement.

Toutefois, quelques surprises se trouvaient également au programme : nous avons effectué un grand pas en avant vers le « Q-Day » (le « Jour de l'avènement du quantique ») en raison de l'amélioration des algorithmes quantiques. L'un d'entre eux nous a d'ailleurs causé une grande frayeur. Voilà un aperçu des sujets que nous aborderons ici, parmi bien d'autres. Nous nous intéresserons également à ce que nous pouvons attendre dans les années à venir et à ce que vous pouvez faire dès aujourd'hui.

Commençons par le commencement. Pourquoi changeons-nous d'approche cryptographique ? Tout bonnement à cause des ordinateurs quantiques. Plutôt que de se limiter aux zéros et aux uns, ces incroyables appareils calculent en s'appuyant sur un ensemble encore plus étendu des possibilités présentées par la nature : la superposition quantique, l'interférence et l'intrication. Ces phénomènes permettent aux ordinateurs quantiques d'exceller dans certains calculs très spécifiques, notamment la simulation de la nature elle-même. Cet aspect s'avérera d'ailleurs très utile pour développer de nouveaux matériaux.

Les ordinateurs quantiques ne remplaceront toutefois pas les ordinateurs classiques. En réalité, ils se révèlent bien moins performants que les ordinateurs classiques pour la plupart des tâches importantes de notre quotidien. Vous pouvez les considérer comme des cartes graphiques ou des moteurs neuronaux : des outils spécialisés dans la réalisation de calculs spécifiques et non des appareils à usage général.

Malheureusement, les ordinateurs quantiques excellent également dans le déchiffrage de méthodes de chiffrement reposant sur des clés encore couramment utilisées aujourd'hui, comme le chiffrement RSA et le chiffrement basé sur les courbes elliptiques (ECC, Elliptic Curve Cryptography). Nous évoluons ainsi vers le chiffrement post-quantique, à savoir une approche cryptographique conçue pour résister aux attaques quantiques. Nous discuterons plus tard de l'impact exact du quantique sur les différents types de chiffrement.

Pour le moment, les ordinateurs quantiques se montrent plutôt anémiques. Ils ne sont tout simplement pas assez performants à l'heure actuelle pour briser les clés cryptographiques utilisées en conditions réelles. Ce n'est pas pour autant que nous devons cesser de nous inquiéter pour le présent. Le trafic chiffré peut ainsi être collecté aujourd'hui et déchiffré après le Q-Day, c'est-à-dire le jour où les ordinateurs quantiques seront capables de briser les méthodes de chiffrement encore largement utilisées à l'heure actuelle, comme le RSA-2048. C'est ce que nous appelons une attaque de type « collecter maintenant, déchiffrer plus tard ».

Si l'on utilise la factorisation comme référence, les ordinateurs quantiques n'impressionnent en aucune façon : le plus grand nombre factorisable par un ordinateur quantique (sans tricher) est 15, un record facilement battu de bien des manières pour le moins « ludiques ». Il est tentant d'ignorer les réalisations des ordinateurs quantiques tant que leurs capacités en matière de factorisation ne surpassent pas celles des ordinateurs classiques, mais ce serait commettre une grave erreur. Toutes les estimations, même les plus prudentes, situent le Q-Day moins de trois ans après le jour où les ordinateurs quantiques parviendront à supplanter les ordinateurs classiques en matière de factorisation. Alors, comment suivre leur progression dans ces circonstances ?

Deux catégories sont à prendre en compte dans la marche vers le Q-Day : les progrès réalisés au niveau du matériel quantique et les améliorations algorithmiques apportées aux logiciels qui fonctionnent sur ces équipements physiques. Nous avons constaté d'importantes évolutions sur ces deux fronts.

La presse annonce tous les ans, avec une régularité d'horlogerie, le lancement de nouveaux ordinateurs quantiques affichant un nombre record de qubits. Toutefois, l'accent mis sur le nombre de qubits se révèle là encore assez trompeur. Pour commencer, les ordinateurs quantiques sont des machines analogiques. Un certain bruit vient donc toujours interférer avec leurs calculs.

De même, de grandes différences existent entre les différents types de technologie utilisées pour bâtir une machine quantique : les ordinateurs quantiques reposant sur le silicium semblent faciles à redimensionner à l'échelle souhaitée et exécutent rapidement les instructions reçues, mais disposent de qubits très bruyants. Ils n'en sont pas inutiles pour autant. En effet, les codes de correction d'erreurs quantiques permettent de transformer efficacement des millions de qubits à base de silicium bruyants en quelques milliers de qubits haute fidélité, soit un nombre qui pourrait suffire à briser le chiffrement RSA. Les ordinateurs quantiques à ions piégés, quant à eux, présentent beaucoup moins de bruit, mais se révèlent plus difficiles à faire évoluer. Seules quelques centaines de milliers de qubits à ions piégés pourraient potentiellement venir à bout du code du RSA-2048.

^{Chronologie du meilleur de l'informatique quantique entre 2021 et 2025. L'axe des abscisses présente le nombre de qubits et celui des ordonnées, le bruit. Les points dans la zone grise représentent les différents ordinateurs quantiques disponibles sur le marché. Le début des problèmes commencera lorsque la zone grisée atteindra la ligne rouge la plus à gauche, car un ordinateur quantique sera alors devenu suffisamment puissant pour casser des clés RSA de grande taille. Graphique compilé par Samuel Jaques, de l'Université de Waterloo.}

Le débat entre le nombre de qubits et le bruit ne fait que commencer. D'autres détails de bas niveau sont susceptibles de faire une grande différence, comme l'interconnexion des qubits, par exemple. Plus important encore, le graphique ne restitue pas le potentiel d'évolution de la technique à l'œuvre derrière ces records.

Ainsi, si l'on s'en réfère aux graphiques, les progrès des ordinateurs quantiques semblent avoir stagné ces deux dernières années. Or, pour les experts, l'annonce de Willow par Google en décembre 2024 (une actualité qui ne se distingue pas particulièrement sur le graphique) représente en réalité un véritable tournant, qui marque le moment où nous avons atteint le premier qubit logique au sein du code de surface, de manière évolutive. Comme le dit lui-même Sam Jaques :

« J'ai eu des frissons lorsque j'ai lu ces résultats [les réalisations de Willow]. Je me suis dit : « Ouah, l'informatique quantique, c'est vraiment une réalité ! »

S'il s'agit là d'un réel bond en avant, nous ne sommes toutefois pas dans l'inattendu. Pour citer Sam à nouveau :

« Malgré mon enthousiasme, nous en sommes plus ou moins là où nous devrions être, voire un peu en retard. Toutes les grandes avancées qui ont été démontrées constituent des étapes que nous devions atteindre pour espérer arriver à la machine de 20 millions de qubits qui se révélera capable de briser le RSA. Ça n'existe pas, une percée inattendue. Tout cela ressemble un peu à l'augmentation annuelle de la densité des transistors sur les puces classiques. Ça reste un exploit impressionnant, mais en fin de compte, c'est un peu la routine habituelle. »

Cette routine habituelle s'applique également à la stratégie : l'approche des qubits supraconducteurs adoptée par Google pour Willow s'est toujours présentée comme le chemin le plus direct pour s'attaquer directement aux difficultés, celle qui nécessitait le moins de bonds technologiques.

Microsoft poursuit la stratégie opposée en pariant sur les qubits topologiques, des qubits qui seraient, en théorie, quasiment insensibles au bruit. Ces derniers n'ont toutefois pas été pleinement concrétisés de manière physique à cette heure. Ils se montreraient éminemment supérieurs aux qubits supraconducteurs s'ils pouvaient être construits sous une forme évolutive, mais nous ne savons même pas s'ils peuvent l'être pour commencer. Au début de l'année 2025, Microsoft a annoncé le processeur Majorana 1, qui montre comment ces qubits pourraient être construits. Cette puce est cependant loin d'être un véritable prototype : elle ne prend en charge aucun calcul et n'apparaît donc même pas dans le graphique comparatif compilé par Sam ci-dessus.

Entre les qubits topologiques et les qubits supraconducteurs, les laboratoires à travers le monde suivent une quantité d'autres approches qui figurent sur le graphique, quant à elles, comme QuEra avec les atomes neutres et Quantinuum avec son approche des ions piégés.

Les progrès concernant l'aspect matériel des machines qui nous permettront d'arriver un jour au Q-Day ont de loin suscité le plus d'intérêt de la part de la presse, mais la plus grande percée de ces deux dernières années se situe toutefois à un autre niveau.

Avec l'approche supraconductrice, nous pensions avoir besoin d'environ 20 millions de qubits pour briser le modèle RSA-2048. Il s'avère que nous pouvons parvenir au même résultat avec beaucoup moins de ressources. Dans un article incroyablement complet datant de juin 2025, Craig Gidney montre qu'avec des optimisations logicielles quantiques intelligentes, nous avons en réalité besoin de moins d'un million de qubits. C'est la raison pour laquelle les lignes rouges du graphique de Sam ci-dessus (qui indiquent la taille que doit atteindre un ordinateur quantique pour casser le RSA) ont opéré une translation spectaculaire vers la gauche en 2025.

Pour mettre cet exploit en perspective, imaginons que Google réussisse à doubler le nombre de qubits physiques tous les 18 mois (un peu comme une sorte de loi de Moore appliquée au quantique). Il s'agit là d'un rythme bien plus rapide que ce à quoi Google nous a habitués jusqu'à présent, mais il n'est pas impensable que l'entreprise puisse y parvenir une fois le travail de fond effectué. Il faudrait ainsi attendre 2052 pour atteindre les 20 millions de qubits, mais seulement 2045 pour atteindre le million. À lui seul, Craig a donc rapproché le Q-Day de sept ans !

Jusqu'où peuvent aller les optimisations logicielles ? Pour Sam, il semble impossible de descendre en dessous des 100 000 qubits supraconducteurs. Il s'attend d'ailleurs à ce que plus de 242 000 qubits supraconducteurs soient nécessaires pour percer le chiffrement RSA-2048. En prenant pour base les suppositions actuelles concernant les progrès de l'informatique quantique, le Q-Day se produirait dès lors en 2039 et 2041 (peut-être un peu plus tard pour cette deuxième date).

L'estimation de Craig repose sur des hypothèses détaillées et raisonnables concernant l'architecture d'un ordinateur quantique à qubits supraconducteurs déployé à grande échelle, mais il s'agit toujours d'une estimation, qui pourrait s'avérer assez éloignée de la réalité en définitive.

Du point de vue algorithmique, nous pourrions non seulement assister à une amélioration des algorithmes quantiques existants lors des années à venir, mais également à la découverte d'algorithmes totalement nouveaux. En avril 2024, Yilei Chen a publié un preprint (prépublication) annonçant la découverte d'un nouvel algorithme quantique pour résoudre certains problèmes concernant les réseaux euclidiens (lattices). S'ils sont proches, ces problèmes restent néanmoins différents de ceux sur lesquels nous nous appuyons pour la technologie de chiffrement post-quantique que nous déployons. Cette actualité a fait grand bruit. Même s'il ne peut s'attaquer à nos algorithmes post-quantiques à l'heure actuelle, l'algorithme de Chen pourrait-il néanmoins être amélioré ? Pour avoir une idée du potentiel d'amélioration, il est nécessaire de bien comprendre ce que l'algorithme accomplit réellement à un niveau supérieur. Or, cette tâche s'avère pour le moins difficile avec l'algorithme de Chen, car il est très complexe, bien plus que l'algorithme quantique de Shor qui va venir à bout du RSA. Il a donc fallu un certain temps aux experts pour commencer à entrevoir les limites de l'approche de Chen. Ces derniers ont d'ailleurs fini par découvrir un bug fondamental au sein de l'algorithme dix jours après sa publication : l'approche ne fonctionne pas. La crise a donc été évitée.

Quels enseignements retirer de cette expérience ? Si l'on observe la situation de manière optimiste, nous restons là dans l'ordinaire du chiffrement. Les réseaux euclidiens sont même en meilleure posture maintenant, car une voie d'attaque potentielle a finalement débouché sur une impasse. D'un point de vue réaliste, l'expérience nous rappelle toutefois que nous avons mis tous nos œufs dans le panier des réseaux euclidiens. Comme nous le verrons plus tard, il n'existe, à l'heure actuelle, aucune véritable alternative qui fonctionne partout et à tous les niveaux.

Les partisans de la distribution quantique de clé (QKD, Quantum Key Distribution) pourraient faire valoir que cette approche résout précisément le problème, car elle s'appuie sur les lois de la nature pour assurer la sécurisation. Cette affirmation doit être prise avec quelques réserves, bien entendu, mais à un niveau plus fondamental, personne n'a encore trouvé comment faire évoluer la QKD au-delà des connexions point à point, comme nous l'expliquons dans cet article de blog.

S'il reste bon de spéculer sur l'approche de chiffrement qui sera balayée par une attaque d'un genre totalement nouveau, n'oublions pas le problème actuel : une grande partie des méthodes de chiffrement voleront certainement en éclats devant les ordinateurs quantiques. Le Q-Day approche à grands pas. Toute la question consiste à savoir quand.

Si vous travaillez dans ou autour du secteur du chiffrement et de la sécurité depuis suffisamment longtemps, vous avez probablement entendu dire que « le Q-Day se produira dans X ans », chaque année, depuis plusieurs années. Ce genre d'affirmation peut donner l'impression que le Q-Day est perpétuellement fixé à « un jour dans le futur »… jusqu'à ce que nous replacions cette affirmation dans le contexte approprié.

Depuis 2019, le Global Risk Institute (l'Institut mondial du risque) contacte des experts dans le cadre d'une enquête annuelle qui les interroge sur la probabilité que le RSA-2048 soit brisé d'ici 5, 10, 15, 20 ou 30 ans. Voici les résultats pour l'année 2024 (les entretiens ont eu lieu avant le lancement de Willow et la découverte de Gidney).

^{Résultats de l'enquête 2024 réalisée auprès d'experts par le Global Risk Institute et concernant la probabilité qu'un ordinateur quantique parvienne à percer le chiffrement RSA-2048 selon différentes chronologies.}

Comme le montre la colonne centrale de ce graphique, plus de la moitié des experts interrogés ont estimé qu'il existait au moins 50 % de chances qu'un ordinateur quantique parvienne à percer le RSA-2048 d'ici 15 ans. Consultons les réponses des années précédentes : 2019, 2020, 2021, 2022 et 2023. Nous considérons ici la probabilité que le Q-Day se produise dans un délai de 15 ans (au moment de l'entretien) :

^{Réponses des rapports précédents sur la chronologie des menaces quantiques concernant la probabilité que le Q-Day survienne dans les 15 ans.}

Le graphique montre que les réponses tendent progressivement vers davantage de certitude, mais augmentent-elles effectivement au rythme que nous pouvons attendre ? Avec six années de réponses, nous pouvons représenter graphiquement la cohérence des prédictions sur une année : l'estimation à 15 ans pour l'année 2019 correspond-elle à l'estimation sur 10 ans de 2024 ?

^{Réponses des rapports précédents sur la chronologie des menaces quantiques concernant la date du Q-Day au fil des ans. L'axe des abscisses montre l'année lors de laquelle le Q-Day devrait censément se produire, tandis que l'axe des ordonnées montre la part des experts interrogés qui pensent qu'il est probable que cet événement survienne à au moins 50 % (à gauche) ou 70 % (à droite).}

Si nous demandons à un panel d'experts à quelle date le Q-Day pourrait avoir lieu, à probabilité égale (graphique de gauche), la plupart d'entre eux continuent à donner la même réponse année après année : oui, ce type d'événement pourrait se produire dans 15 ans. Toutefois, si nous insistons pour qu'ils se prononcent avec davantage de certitude, soit avec une probabilité supérieure à 70 % (graphique de droite) que le Q-Day se produise, les experts restent généralement cohérents au fil des ans. Un cinquième des personnes interrogées ont pensé à l'année 2034 lors des enquêtes réalisées en 2019 et en 2024, par exemple.

Donc, si vous souhaitez obtenir une réponse cohérente de la part d'un expert, ne lui demandez pas la date du Q-Day, mais plutôt à quelle date il est probable qu'il se produise. S'il peut être amusant d'essayer de deviner à quel moment le Q-Day surviendra, la seule réponse honnête est que personne ne peut le savoir avec certitude. Trop d'inconnues entrent en jeu, tout simplement. En fin de compte, la date du Q-Day se révèle bien moins importante que les dates limites définies par les organismes de réglementation.

Nous pouvons également examiner les calendriers des différentes autorités de réglementation. En 2022, la National Security Agency (NSA, l'Agence nationale de la sécurité américaine) a publié ses directives CNSA 2.0, qui fixent une date d'échéance située entre 2030 et 2033 pour la migration vers le chiffrement post-quantique. Toujours en 2022, le gouvernement fédéral américain a fixé l'année 2035 comme date-limite pour la migration complète des États-Unis. La nouvelle administration n'a pas remis en question cet objectif. En 2024, l'Australie a défini l'année 2030 comme date d'échéance forte pour sa migration. Début 2025, le NCSC britannique a fixé l'année 2035 comme date limite pour le Royaume-Uni. Mi-2025, l'Union européenne a publié sa feuille de route, avec des échéances fixées entre 2030 et 2035 en fonction de l'application.

Toutes les autorités réglementaires nationales n'ont pas défini de chronologie pour la migration vers le post-quantique, mais celles qui l'ont fait s'en tiennent généralement à la période 2030-2035.

À quelle date les ordinateurs quantiques commenceront-ils à poser problème ? Que ce soit en 2034 ou en 2050, cette date arrivera certainement trop tôt. L'immense succès rencontré par le chiffrement depuis plus de cinquante ans implique son omniprésence dans notre vie quotidienne, des lave-vaisselles aux stimulateurs cardiaques en passant par les satellites. La plupart des initiatives de modernisation s'effectueront facilement et s'intégreront naturellement au cycle de vie du produit, mais il ne faudra pas occulter la longue traîne de mises à niveau difficiles et coûteuses.

Intéressons-nous maintenant au processus de migration vers le chiffrement post-quantique.

Afin de faciliter la hiérarchisation, il est important de comprendre que les différents types de chiffrement nécessaires à l'établissement de connexions sécurisées présentent des différences significatives en termes de difficulté, d'impact et d'urgence du processus de migration post-quantique. En réalité, la plupart des entreprises procéderont à deux migrations post-quantiques : la migration des accords de clé et la migration des signatures/certificats. Nous allons expliquer le fonctionnement de ces deux migrations en prenant pour contexte l'établissement d'une connexion sécurisée lors de la visite d'un site web à l'aide d'un navigateur.

Le chiffrement symétrique (comme l'algorithme AES-GCM) constitue l'épine dorsale cryptographique d'une connexion. Il représente exactement ce que l'on imagine lorsque l'on pense au chiffrement : les deux parties (ici le navigateur et le serveur) partagent une clé et chiffrent/déchiffrent leurs messages à l'aide de cette même clé. Un utilisateur ne peut rien lire ni modifier à moins de disposer de cette clé.

La bonne nouvelle, c'est que les algorithmes de chiffrement symétrique (comme l'AES-GCM donc) sont déjà sécurisés contre le post-quantique. On pense souvent à tort que l'algorithme quantique de Grover nous contraint à doubler la longueur des clés symétriques. Après examen plus approfondi de cet algorithme, il est évident que cette opération n'est pas réalisable dans la pratique. La manière dont le NIST (National Institute of Standards and Technology, l'Institut national des normes et de la technologie des États-Unis, qui mène les efforts de normalisation du chiffrement post-quantique) définit ses niveaux de sécurité post-quantique s'avère particulièrement révélatrice. Il définit un niveau de sécurité spécifique en indiquant que le mécanisme devrait être aussi difficile à déchiffrer, à l'aide d'un ordinateur classique ou quantique, qu'un algorithme de chiffrement symétrique existant. Ces niveaux sont les suivants :

Niveau	Définition : au moins aussi difficile à percer que…	Exemple
1	De récupérer une clé AES-128 en la recherchant par force brute	ML-KEM-512, SLH-DSA-128s
2	De trouver une collision au sein du chiffrement SHA256 en la recherchant par force brute	ML-DSA-44
3	De récupérer une clé AES-192 en la recherchant par force brute	ML-KEM-768, ML-DSA-65
4	De trouver une collision au sein du chiffrement SHA384 en la recherchant par force brute
5	De récupérer une clé AES-256 en la recherchant par force brute	ML-KEM-1024, SLH-DSA-256s, ML-DSA-87

^{Niveaux de sécurité de la PQC du NIST. Plus le niveau est élevé, plus l'algorithme est difficile à percer (« plus sécurisé »). Nous aborderons le ML-DSA, le SLH-DSA et le ML-KEM en tant qu'exemples un peu plus loin dans la page.}

La suggestion consistant à doubler la longueur de la clé de chiffrement symétrique part d'une bonne intention. Dans de nombreux scénarios d'utilisation, le coût supplémentaire de cette opération n'est pas si élevé et ce fait atténue les éventuels risques théoriques. La mise à l'échelle souhaitée du chiffrement symétrique s'avère également peu coûteuse. Un nombre de bits doublé coûte ainsi généralement beaucoup moins que la moitié du coût. Il s'agit donc d'un simple conseil en apparence.

Ainsi, si nous insistons sur le déploiement du chiffrement AES-256, il semble également logique d'insister sur le déploiement d'une solution correspondant au niveau 5 de la CPQ du NIST en ce qui concerne le chiffrement à clé publique. Le problème, c'est que le chiffrement à clé publique n'est pas très facile à faire évoluer à l'échelle souhaitée. Selon le mécanisme utilisé, la différence entre le niveau 1 et le niveau 5 entraîne une multiplication par plus de deux de l'utilisation des données et des coûts processeur. Comme nous le verrons plus bas, si le déploiement de signatures post-quantiques au niveau 1 se révèle déjà pénible, leur déploiement au niveau 5 est tout bonnement incapacitant.

Plus important encore, les entreprises ne disposent que de ressources limitées. Nous ne souhaitons pas qu'une entreprise privilégie la migration vers le chiffrement AES-128 en devant pour ce faire maintenir le chiffrement RSA, clairement vulnérable à l'informatique quantique.

Les algorithmes de chiffrement symétrique ne suffisent pas à eux seuls. Comment savoir quelle clé utiliser lorsque je me rends sur un site web pour la première fois ? Le navigateur ne peut pas se contenter d'envoyer une clé aléatoire, car n'importe quel acteur en train d'écouter la communication verrait également la clé. On pourrait penser l'opération impossible, mais il est possible de passer par des calculs mathématiques ingénieux pour résoudre ce problème afin que le navigateur et le serveur puissent s'accorder sur une clé partagée. Ce type de dispositif s'appelle un mécanisme d'accord de clé. Il est mis en œuvre lors de la négociation TLS. En 2024, la quasi-totalité du trafic est sécurisée à l'aide du X25519, un mécanisme d'accord de clé de type Diffie-Hellman, mais sa sécurité est totalement compromise par l'algorithme de Shor sur un ordinateur quantique. Toutes les communications sécurisées à l'aide du protocole Diffie-Hellman (et actuellement stockées) pourront être déchiffrées plus tard par un ordinateur quantique.

Il est donc urgent de procéder dès aujourd'hui à la mise à niveau des mécanismes d'accord de clé. Fort heureusement, le déploiement d'un mécanisme d'accord de clé post-quantique s'avère relativement simple. En outre, comme nous l'avons vu précédemment, la moitié des requêtes adressées à Cloudflare fin 2025 sont déjà sécurisées par un tel mécanisme !

L'accord de clé permet un échange de clés sécurisé, mais le processus comporte néanmoins une lacune importante : nous ne savons pas avec qui nous nous sommes accordés sur la clé. Si nous nous contentions de procéder à un simple échange de clés, un acteur malveillant en position d'interception pourrait effectuer des échanges distincts avec le navigateur et le serveur, avant de rechiffrer l'ensemble des messages échangés. Un dernier ingrédient est nécessaire pour éviter cette situation : l'authentification.

L'opération est rendue possible par l'utilisation de signatures. Lorsque vous vous rendez sur un site web, comme cloudflare.com, par exemple, le serveur web présente un certificat signé par une autorité de certification (CA, Certification Authority) qui atteste que la clé publique de ce certificat est bien contrôlée par cloudflare.com. Le serveur web signe ensuite la négociation et la clé partagée à l'aide de la clé privée correspondant à la clé publique présente dans le certificat. Ce processus permet au client de s'assurer qu'il a bien passé un accord de clé avec cloudflare.com.

Deux mécanismes de signature traditionnels, le RSA et l'ECDSA, sont fréquemment utilisés aujourd'hui. Là encore, en permettant à un pirate quantique de falsifier n'importe quelle signature, l'algorithme de Shor les balaie en un instant. Un acteur malveillant disposant d'un ordinateur quantique peut donc usurper l'identité d'un utilisateur (et procéder à une attaque de l'homme du milieu, également appelée MitM, « Man-in-the-Middle ») sur n'importe quel site web pour lequel nous acceptons des certificats non préparés pour le post-quantique.

Ce type d'attaque ne pourra être lancé qu'une fois les ordinateurs quantiques capables de déchiffrer le RSA/l'ECDSA. À première vue, cette constatation rend la mise à niveau des mécanismes de signature TLS moins urgente, car il suffit que tout le monde ait terminé sa migration avant le Q-Day. Nous verrons malheureusement que la migration vers les signatures post-quantiques s'avère bien plus difficile que prévu et demandera davantage de temps.

Avant de nous intéresser plus en détail aux défis techniques liés à la migration de l'Internet vers le chiffrement post-quantique, examinons de quelle manière nous en sommes arrivés là et ce à quoi nous pouvons attendre dans les années à venir. Commençons par la genèse du chiffrement post-quantique.

Les physiciens Feynman et Manin ont suggéré le concept d'ordinateurs quantiques en indépendants vers 1980. Il faudra attendre encore 14 ans avant que Shor ne publie son algorithme remettant en cause les modèles de chiffrement RSA et ECC. Les méthodes de chiffrement post-quantique sont, pour la plupart, antérieures au célèbre algorithme de Shor.

Le domaine du chiffrement post-quantique se décompose en différentes branches, dont les plus importantes reposent sur les réseaux euclidiens (lattice-based), sur les fonctions de hachage (hash-based), sur l'analyse multivariée (multivariate), sur le code (code-based) et sur les isogénies (isogeny-based). À l'exception du chiffrement basé sur les isogénies, aucune de ces méthodes n'a été conçue à l'origine pour la cryptographie post-quantique. En réalité, les premiers schémas basés sur le code et sur les fonctions de hachage sont contemporains du RSA. Initialement proposés dans les années 1970, ils sont donc largement antérieurs à la publication de l'algorithme de Shor en 1994. De même, le premier schéma multivarié remonte à 1988 et s'avère donc bien plus ancien que l'algorithme de Shor. Ainsi, c'est par un pur hasard que la branche la plus performante, le chiffrement basé sur les réseaux euclidiens, se révèle la plus proche contemporaine de Shor (elle a été proposée en 1996). À titre de comparaison, le chiffrement basé sur les courbes elliptiques (largement utilisée aujourd'hui) a été proposé pour la première fois en 1985.

Dans les années qui ont suivi la publication de l'algorithme de Shor, les cryptographes ont évalué le panorama existant du chiffrement : quels sont les aspects qui ne fonctionnent manifestement plus et comment pourrait-on imaginer le post-quantique ? Le premier atelier international annuel consacré au chiffrement post-quantique s'est déroulé en 2006. Un texte introductif, qui constitue toujours une bonne introduction à ce champ d'études, a été préparé à l'issue de cette conférence. La chute du mécanisme de signature Rainbow constitue néanmoins une mise en garde notable. Le mécanisme d'accord de clé sur courbes elliptiques X25519 a été proposé cette même année (2006). Il sécurise désormais la majorité des connexions Internet, que ce soit de manière autonome ou hybride, à l'aide du ML-KEM-768 post-quantique. 

Dix ans plus tard, en 2016 donc, le NIST a lancé un concours public consacré à la normalisation du chiffrement post-quantique. À cette occasion, l'institut a employé un format ouvert similaire à celui qui a servi à normaliser l'AES en 2001 et le SHA3 en 2012. Tout le monde pouvait participer au concours en soumettant des mécanismes et en évaluant les propositions. Les cryptographes du monde entier ont envoyé leurs algorithmes pour examen. Afin de concentrer les efforts, la liste de propositions a été réduite après trois tours. Sur les 82 algorithmes initialement soumis, huit ont été sélectionnés sur la base des commentaires du public et ont atteint la finale. Parmi ces huit finalistes, le NIST a choisi en 2022 d'en sélectionner quatre à normaliser en premier : un KEM (pour « Key Agreement », accord de clé) et trois mécanismes de signature.

Ancien nom	Nouveau nom	Branche
Kyber	ML-KEM (FIPS 203) Module-lattice based Key-Encapsulation Mechanism Standard (norme de mécanisme d'encapsulation de clé basé sur un réseau euclidien modulaire)	Réseau euclidien
Dilithium	ML-DSA (FIPS 204) Module-lattice based Digital Signature Standard (norme de signature numérique basée sur un réseau euclidien modulaire)	Réseau euclidien
SPHINCS+	SLH-DSA (FIPS 205) Stateless Hash-Based Digital Signature Standard (norme de signature numérique basée sur le hachage et sans persistance)	Hachage
Falcon	FN-DSA (pas encore normalisée) FFT over NTRU lattices Digital Signature Standard (norme de signature numérique FFT sur réseaux euclidiens NTRU)	Réseau euclidien

Les normes finales correspondant aux trois premiers de la liste ont été publiées en août 2024. La FN-DSA a pris du retard et nous en discuterons plus loin.

Le ML-KEM est le seul mécanisme d'accord de clé post-quantique normalisé à ce jour. Il s'agit en outre d'une mise à niveau plutôt facile à mettre en œuvre, malgré certaines difficultés occasionnelles liées à la plus grande taille des clés.

La situation est plutôt différente du côté des signatures. Il est d'ailleurs assez révélateur que le NIST ait déjà choisi d'en normaliser trois. Le nombre de signatures devant être normalisées sera encore plus élevé à l'avenir. Ce constat s'explique par le fait qu'aucun des modèles de signatures proposés ne se révèle particulièrement idéal. En résumé, nous disposons tous aujourd'hui de clés et de signatures de taille beaucoup plus importante que celles auxquelles nous sommes habitués.

Du point de vue de la sécurité, le SLH-DSA constitue le choix le plus prudent, mais également le moins performant. En ce qui concerne la taille des clés publiques et des signatures, le FN-DSA l'emporte clairement sur les trois autres, mais le processus de signature se révèle difficile à déployer en toute sécurité du fait de son modèle arithmétique à virgule flottante. En raison de l'applicabilité limitée et de la complexité de conception du FN-DSA, le NIST a choisi de se concentrer en premier lieu sur les trois autres mécanismes.

Le ML-DSA constitue donc le choix par défaut. Vous trouverez des comparatifs plus approfondis ci-dessous.

Le simple fait de disposer de normes définies par le NIST ne suffit pas. Il est également nécessaire d'uniformiser la manière dont les nouveaux algorithmes sont utilisés dans les protocoles de niveau supérieur. Dans de nombreux cas, comme le mécanisme d'accord de clé utilisé par le protocole TLS, rien de plus simple : il suffit d'attribuer un identifiant aux nouveaux algorithmes. Dans d'autres, comme pour le DNSSEC, l'opération demande un peu plus de réflexion. De nombreux groupes de travail de l'IETF se préparent depuis des années à l'arrivée des normes finales du NIST. Quant à nous, nous nous attendions à ce que de nombreuses intégrations de protocoles soient finalisées peu après, soit avant la fin de l'année 2024. Cette estimation s'est révélée trop optimiste : certaines normes sont terminées, mais beaucoup d'autres en sont loin.

Commençons par les bonnes nouvelles et intéressons-nous aux normes finalisées.

• Le mécanisme d'accord de clé TLS hybride X25519MLKEM768, qui allie le X25519 et le ML-KEM-768 (nous y reviendrons plus tard), est prêt à l'emploi et, dans les faits, largement déployé. D'autres protocoles adoptent également le ML-KEM sous un mode de fonctionnement hybride, comme l'IPsec, prêt à l'emploi pour les configurations simples. (Un petit problème reste à résoudre pour certaines configurations. Nous aborderons le sujet dans un prochain article de blog.) Il peut être surprenant de constater que les RFC correspondantes n'aient pas encore été publiées. Toutefois, l'enregistrement d'un mécanisme d'accord de clé TLS ou IPsec ne nécessite pas de RFC. Dans les deux cas, la RFC est toujours en application afin d'éviter toute forme de confusion pour ceux qui attendent une RFC. Pour le TLS, il est nécessaire d'identifier l'accord de clé comme recommandé.

• En ce qui concerne les signatures, l'intégration du ML-DSA aux certificats X.509 et au protocole TLS est prête. La première norme est une RFC fraîchement définie, tandis que la seconde n'en a pas besoin.

Passons maintenant aux mauvaises nouvelles. Au moment de la rédaction de cet article, soit en octobre 2025, l'IETF n'a pas encore défini la marche à suivre pour les certificats hybrides, c'est-à-dire les certificats qui combinent un mécanisme de signature post-quantique et un mécanisme de signature traditionnel. L'opération est toutefois presque terminée. Nous espérons que le problème sera résolu d'ici le début de l'année 2026.

Mais quelle est donc la cause de ce retard s'il suffit d'attribuer quelques identifiants ? Il s'agit surtout d'une question de choix. Commençons par les choix qui ont dû être faits pour le ML-DSA.

Les deux principaux sujets de discussion concernant les certificats ML-DSA tournaient autour du pré-hachage (prehashing) et du format des clés privées.

Le pré-hachage désigne le processus par lequel une partie du système hache le message, tandis qu'une autre crée les signatures finales. Cette approche s'avère utile si vous ne souhaitez pas envoyer un fichier volumineux à un HSM pour signature. Les premières versions du ML-DSA prenaient en charge le pré-hachage à l'aide du SHAKE256, mais l'opération n'était pas évidente. Le NIST a inclus deux variantes dans la version finale du ML-DSA : le ML-DSA standard et une version avec pré-hachage explicite, dans laquelle vous pouvez choisir n'importe quel type de hachage. Le fait de disposer de différentes variantes n'est pas idéal, car les utilisateurs devront choisir laquelle utiliser. Or, tous les logiciels pourraient ne pas prendre pas en charge l'ensemble des variantes. De même, un processus de tests/validations doit être suivi pour chacune d'elles. Le fait de vouloir choisir une seule variante ne prête aucunement à controverse, mais toute la question consiste à déterminer laquelle. Après de nombreux débats, c'est le ML-DSA standard qui a été choisi.

Le deuxième point concerne le format des clés privées. Vu la manière dont les candidats sont comparés aux référentiels de performances, la possibilité de mettre en cache certains calculs au sein de la clé privée constitue un bon point de la version ML-DSA originale. L'opération implique que la clé privée sera plus volumineuse (plusieurs kilo-octets) qu'elle n'a besoin de l'être et nécessitera davantage d'étapes de validation. L'une des suggestions visait à réduire la clé privée à l'essentiel : une simple graine de 32 octets. Pour la norme finale, le NIST a décidé d'autoriser à la fois la graine et la clé privée originale, de plus grande taille. Cette situation n'est pas idéale : mieux vaut s'en tenir à l'une des deux options. Dans ce cas précis, l'IETF n'est pas parvenu à faire un choix et a même ajouté une troisième option : une paire contenant à la fois la graine et la clé privée étendue. Techniquement, presque tout le monde s'accordait à dire que la graine constitue le meilleur choix, mais la raison pour laquelle elle n'a pas obtenu la préférence réside dans le fait que certains fournisseurs avaient déjà créé des clés pour lesquelles ils n'avaient pas conservé la graine. Oui, nous sommes déjà en présence d'un héritage post-quantique. Il a fallu près d'un an pour parvenir à ces deux choix.

De nombreux choix supplémentaires doivent être effectués pour définir un mécanisme de signature ML-DSA hybride. Avec quel mécanisme traditionnel associer le ML-DSA ? Quels sont les niveaux de sécurité de chaque côté ? Nous devons ensuite également faire des choix pour les deux mécanismes : quel format de clé privée utiliser ? Quel type de hachage utiliser avec l'ECDSA ? Les mécanismes hybrides soulèvent de nouvelles questions qui leur sont propres. Comptons-nous autoriser la réutilisation des clés au sein du mécanisme hybride et, si oui, souhaitons-nous empêcher les attaques par suppression ? La question du pré-hachage revient en outre avec une troisième option : le pré-hachage au niveau hybride.

Le projet d'octobre 2025 relatif aux signatures hybrides ML-DSA contient 18 variantes, contre 26 l'année précédente. Tout le monde s'accorde à dire encore une fois que ce nombre est bien trop important, mais le processus de réduction pour parvenir à ce nombre s'est avéré bien difficile. Afin d'aider les utilisateurs finaux à choisir, une courte liste a été ajoutée à l'ensemble. Elle a commencé avec trois options, mais s'est retrouvée bien vite étendue à six, bien sûr. Parmi ces mécanismes, nous pensons que le MLDSA44-ECDSA-P256-SHA256 bénéficiera d'un large soutien et sera utilisé de manière généralisée sur Internet.

Revenons maintenant au mécanisme d'accord de clé pour lequel les normes ont été établies.

L'étape suivante est le support logiciel. Tous les écosystèmes ne peuvent pas évoluer à la même vitesse, mais nous avons constaté une adoption importante du mécanisme d'accord de clé post-quantique pour contrer la stratégie « stocker maintenant, déchiffrer plus tard ». Les versions récentes de tous les principaux navigateurs ont activé le X25519MLKEM768 par défaut, de même que de nombreuses bibliothèques et plateformes TLS, notamment OpenSSL, Go et les systèmes d'exploitation Apple récents. Nous vous proposons une vue d'ensemble ici.

Là encore, une grande différence existe entre le mécanisme d'accord de clé et les signatures pour le protocole TLS. Pour le mécanisme d'accord de clé, le serveur et le client peuvent ajouter et activer la prise en charge de l'accord post-quantique de manière indépendante. Une fois la fonctionnalité activée des deux côtés, la négociation TLS utilisera un mécanisme d'accord de clé post-quantique. Nous détaillons le processus de la négociation TLS dans cet article de blog. Si votre produit utilise uniquement le TLS, le problème du « stocker maintenant, déchiffrer plus tard » pourrait être résolu par une simple mise à jour logicielle de votre bibliothèque TLS.

Les certificats TLS post-quantiques se révèlent plus problématiques. À moins de contrôler les deux extrémités de la connexion, vous devrez installer deux certificats : un certificat post-quantique pour les nouveaux clients et un certificat traditionnel pour les anciens. Si vous n'utilisez pas encore de fonctionnalité automatisée d'émission de certificats, le moment pourrait être bien choisi pour vous informer sur cette dernière. Le protocole TLS permet au client d'annoncer les mécanismes de signature qu'il prend en charge afin que le serveur puisse choisir de diffuser un certificat post-quantique uniquement aux clients qui supportent cette fonctionnalité. Malheureusement, tous les serveurs n'exposent pas cette configuration, même si la quasi-totalité des bibliothèques TLS prennent en charge la configuration de plusieurs certificats. Dans la plupart des cas, l'opération nécessitera néanmoins une modification de la configuration. (Bien entendu, caddy s'en chargera sans doute pour vous.)

À propos des certificats post-quantiques d'ailleurs, il faut savoir que les autorités de certification (CA) auront besoin d'un certain temps avant de pouvoir les émettre. Leurs HSM auront d'abord besoin d'un support (physique), qui devra ensuite faire l'objet d'un audit. Le forum CA/Browser devra en outre approuver l'utilisation des nouveaux algorithmes. Les programmes racines, quant à eux, ont des optiques divergentes concernant les délais. D'après les rumeurs, l'un des programmes racines préparerait un pilote visant à accepter les certificats ML-DSA-87 d'une durée d'un an, avec un lancement prévu potentiellement avant la fin de l'année 2025. Pour étayer cette actualité, un sondage est d'ailleurs en cours sur le forum CA/Browser. De son côté, Chrome préfère résoudre le problème des certificats de grande taille en priorité. Les audits risquent d'être le principal goulot d'étranglement pour les primo-adoptants, car les CA s'attendent à recevoir une foule de demandes après la publication des normes NIST. S'il est certain que nous verrons les premiers certificats post-quantiques en 2026, il est toutefois peu probable que ces derniers soient largement disponibles ou reconnus par tous les navigateurs avant 2027.

Nous sommes dans une période intermédiaire intéressante : une grande partie du trafic Internet est protégée par des accords de clé post-quantiques, mais aucun certificat post-quantique public n'est en cours d'utilisation.

Le NIST n'a pas tout à fait terminé de normaliser le chiffrement post-quantique. Deux autres concours post-quantiques sont en cours : le quatrième tour et le tremplin signatures.

Le NIST n'a normalisé qu'un seul mécanisme d'accord de clé post-quantique jusqu'à présent : le ML-KEM. L'institut aimerait en normaliser un deuxième afin de disposer d'un KEM de secours qui ne soit pas basé sur les réseaux euclidiens, au cas où ceux-ci s'avéreraient moins solides que prévu. Il a ajouté pour ce faire un quatrième tour au concours initial afin de choisir un KEM de secours parmi les finalistes. Le HQC a ainsi été sélectionné en mars 2025 afin d'être normalisé.

Le mécanisme HQC affiche des performances bien inférieures au ML-KEM pour chaque indicateur. Le HQC-1, la variante au niveau de sécurité le plus bas, nécessite une transmission de 7 Ko de données. C'est presque le double des 3 Ko nécessaires au ML-KEM-1024, la variante au niveau de sécurité le plus élevé pour ce mécanisme. On observe un écart similaire en matière de performances processeur. Le HQC évolue en outre de moins en moins bien lorsque le niveau de sécurité augmente. Alors que le ML-KEM-1024 demande environ le double de ressources par rapport au ML-KEM-512, le niveau de sécurité le plus élevé du HQC consomme trois fois plus de données (21 Ko !) et nécessite une puissance de calcul plus de quatre fois supérieure.

Qu'en est-il du point de vue de la sécurité ? Le ML-KEM-768 présente un avantage certain sur le HQC-1 en ce qui concerne la possibilité de se prémunir contre l'amélioration progressive des attaques : il est beaucoup plus performant et sa marge de sécurité au niveau 3 est énorme par rapport à celle du niveau 1. Et en ce qui concerne les sauts ? Le ML-KEM et le HQC s'appuient tous deux sur une structure algébrique similaire, qui repose respectivement sur les réseaux euclidiens et les codes. Il n'est ainsi pas inconcevable qu'une percée dans ce domaine puisse s'appliquer aux deux mécanismes. Les codes et les réseaux euclidiens semblent donc désormais liés, même sans la structure algébrique. Nous sommes toutefois là en pleine spéculation : une attaque d'ampleur catastrophique sur les réseaux euclidiens pourrait en effet ne pas affecter les codes, mais il ne serait pas non plus étonnant que ces derniers soient touchés de la même manière. Après tout, le RSA et l'ECC, qui présentent encore moins de similitudes, sont tous deux anéantis par les ordinateurs quantiques.

La possibilité de conserver le HQC à portée de main, juste au cas où, pourrait néanmoins nous permettre de garder l'esprit tranquille. À ce stade, nous souhaiterions vous faire part d'une anecdote issue de la semaine chaotique où nous ne savions pas encore que l'algorithme quantique de Chen contre les réseaux euclidiens comportait des lacunes. Par quoi allions-nous remplacer le ML-KEM si ces réseaux étaient affectés ? Le HQC a été brièvement envisagé, mais il apparaissait clairement qu'une variante ajustée du ML-KEM se révélerait bien plus performante.

En prenant un peu de recul, le fait que nous soyons à la recherche d'un deuxième KEM efficace constitue un véritable luxe. Si je pouvais faire un vœu concernant un nouveau mécanisme post-quantique, je ne demanderais pas un meilleur KEM, mais un meilleur mécanisme de signature. Voyons si mon vœu est exaucé.

Après l'annonce des quatre premiers lauréats fin 2022, le NIST a également lancé un nouveau concours, baptisé tremplin signatures (Signatures Onramp), afin de trouver d'autres mécanismes de signature. Ce concours présente deux objectifs. La première consiste à se prémunir contre les avancées cryptanalytiques à l'encontre du chiffrement basé sur les réseaux euclidiens. Le NIST souhaiterait normaliser un mécanisme de signature plus performant que le SLH-DSA (à la fois en termes de taille et de puissance de calcul), mais qui ne repose pas sur ce type de réseaux. Deuxièmement, l'institut recherche un mécanisme susceptible de s'en sortir avec les honneurs dans les scénarios d'utilisation où les outils actuels ne donnent pas de bons résultats. Nous en discuterons de manière détaillée plus loin dans cet article.

En juillet 2023, le NIST a publié les 40 projets reçus à l'occasion du premier tour d'examens publics. La communauté cryptographique s'est mise au travail et, comme de juste pour un premier tour, de nombreux mécanismes ont été invalidés en une semaine. Dix projets avaient été totalement éliminés une fois le mois de février 2024 arrivé et plusieurs autres ont été considérablement affaiblis. En octobre 2024, le NIST a sélectionné 14 projets pour le second tour parmi les candidats restants en lice.

Nous avons publié un article de blog traitant de ces 14 projets dans le détail l'année dernière. En bref, des progrès considérables ont été réalisés en matière de mécanismes de signature post-quantique. Nous les évoquerons brièvement plus tard et ferons le point sur les avancées survenues depuis l'année dernière. Il convient de mentionner qu'à l'instar de la manière dont le principal concours post-quantique se déroule, le processus de sélection demandera de nombreuses années. Il est peu probable qu'un des mécanismes issus du tremplin signatures soit normalisé avant 2028, si tant est qu'il ne soit pas invalidé d'ici là. Nous ne pouvons ainsi pas avoir la certitude que de meilleurs mécanismes de signature résoudront nos problèmes actuels, même si ces systèmes seront bien entendu plus que bienvenus à l'avenir. Comme l'écrit Eric Rescorla, l'éditeur du TLS 1.3 : « On part au front avec les algorithmes dont on dispose, pas avec ceux dont on aimerait disposer. »

Conservons ces éléments en mémoire et intéressons-nous aux progrès concernant les déploiements.

Maintenant que nous disposons d'une vue d'ensemble, examinons de plus près certains détails du mécanisme X25519MLKEM768, désormais largement déployé.

Penchons-nous en premier lieu sur la partie post-quantique. Le mécanisme ML-KEM a été soumis sous le nom CRYSTALS-Kyber. Bien qu'il s'agisse d'une norme américaine, ses concepteurs travaillent dans les milieux professionnels et universitaires en France, en Suisse, aux Pays-Bas, en Belgique, en Allemagne, au Canada, en Chine et aux États-Unis. Jetons un œil à ses performances.

À l'heure actuelle, la vaste majorité des clients utilisent le mécanisme d'accord de clé traditionnel X25519. Comparons-le au ML-KEM.

^{Comparatif des différences en termes de taille et d'efficacité processeur entre le X25519 et le ML-KEM. Les performances varient considérablement selon la plateforme matérielle et les contraintes de mise en œuvre. Elles ne sont données ici qu'à titre d'indication approximative.}

Les variantes ML-KEM-512, ML-KEM-768 et ML-KEM-1024 sont conçues pour se montrer aussi résistantes aux attaques (quantiques) que les algorithmes AES-128, AES-192 et AES-256, respectivement. Même au niveau de l'AES-128, le ML-KEM s'avère beaucoup plus volumineux que le X25519. Il nécessite ainsi une transmission de 800 + 768, soit 1 568 octets, là où le X25519 n'en nécessite que 64.

À l'inverse, le ML-KEM (même le ML-KEM-1024) se montre bien beaucoup plus rapide que le X25519, bien que les chiffres réels puissent varier considérablement en fonction de votre plateforme et de votre déploiement.

Nous ne profitons pas encore de cette augmentation de vitesse. Comme beaucoup d'autres primo-adoptants, nous préférons la sécurité et ainsi déployer un mécanisme d'accord de clé hybride, qui allie le X25519 et le ML-KEM-768. Cette combinaison pourrait vous surprendre pour deux raisons.

1. Pourquoi combiner le X25519 (« 128 bits de sécurité ») et le ML-KEM-768 (« 192 bits de sécurité ») ?

2. Pourquoi s'encombrer du X25519 alors qu'il n'est pas post-quantique ?

Le décalage apparent en termes de niveau de sécurité constitue une protection contre les améliorations cryptanalytiques en matière de chiffrement basé sur les réseaux euclidiens. La sécurité (non post-quantique) du X25519 jouit d'une grande confiance. Il est déjà plus que suffisant d'égaler le niveau de l'AES-128. Ainsi, même si nous sommes à l'aise avec la sécurité du ML-KEM-512 à l'heure actuelle, la cryptanalyse pourrait progresser au cours des prochaines décennies. Nous souhaiterions donc conserver une marge pour le moment.

Le X25519 a été inclus pour deux raisons. Premièrement, il existe toujours une faible probabilité qu'une avancée technologique rende toutes les variantes de ML-KEM caduques. Dans ce cas, le X25519 continuera à assurer une sécurité non post-quantique et notre processus de migration vers le post-quantique n'aura pas aggravé la situation.

Plus important encore, nous devons non seulement nous soucier des attaques contre l'algorithme, mais aussi de la mise en œuvre de la sécurité. Le cas de la vulnérabilité KyberSlash, une attaque temporelle qui a affecté de nombreux déploiements du mécanisme Kyber (une version antérieure du ML-KEM), notamment le nôtre, constitue un exemple notable de moment où nous avons évité le pire. Fort heureusement, la vulnérabilité KyberSlash n'affecte pas le mécanisme Kyber lorsqu'il est utilisé dans un déploiement TLS. Une erreur de mise en œuvre similaire susceptible d'affecter effectivement le TLS nécessiterait probablement l'implication d'un acteur malveillant actif. Dans ce cas, l'objectif probable de ce dernier ne serait pas de déchiffrer des données dans plusieurs décennies, mais de dérober un cookie ou un jeton, voire d'injecter du contenu malveillant. L'inclusion du mécanisme X25519 empêche ce type d'attaque.

Alors, dans la pratique, à quel point le ML-KEM-768 et le X25519 fonctionnent-ils bien en association ?

Consciente des problèmes potentiels en matière de compatibilité et de performances, Google a lancé une première expérience de chiffrement post-quantique dès 2016, soit la même année où le NIST a proposé son concours. L'opération a été suivie d'une deuxième expérience menée de manière conjointe par Cloudflare et Google en 2018. Nous avons testé deux mécanismes hybrides d'accord de clé post-quantique : le CECPQ2 (une combinaison entre le NTRU-HRSS basé sur les réseaux euclidiens et le X25519) et le CECPQ2b (une combinaison entre le mécanisme SIKE, basé sur les isogénies, et le X25519). Le NTRU-HRSS est très similaire au ML-KEM en termes de taille, mais un peu plus exigeant au niveau des calculs côté client. Le SIKE, quant à lui, utilise des clés de très petite taille, s'avère particulièrement coûteux en termes de puissance de calcul et a été totalement invalidé en 2022. La combinaison X25519+NTRU-HRSS s'est révélée très performante en ce qui concerne les temps nécessaires à l'établissement d'une négociation TLS.

Une petite (mais néanmoins significative) proportion de clients a malheureusement rencontré des problèmes de connexion avec le NTRU-HRSS du fait de la taille des partages de clé NTRU-HRSS. Par le passé, le premier message envoyé par le client lors de l'établissement d'une connexion TLS (le ClientHello) tenait presque toujours dans un seul paquet réseau. La spécification TLS permet un ClientHello plus long, mais personne ne s'est vraiment servi de cette possibilité jusqu'ici. L'ossification des protocoles frappe ainsi à nouveau, car certains boîtiers intermédiaires, équilibreurs de charge et autres logiciels partent tacitement du principe que le ClientHello tient toujours dans un paquet unique.

Au cours des années suivantes, nous avons poursuivi nos expérimentations post-quantiques avec l'adoption de Kyber en 2022, puis du ML-KEM en 2024. Chrome a effectué un travail remarquable de contact des fournisseurs dont les produits se révélaient incompatibles. Sans ces problèmes de compatibilité, nous aurions probablement vu Chrome adopter les mécanismes d'accord de clé post-quantiques cinq ans plus tôt. En effet, il a fallu attendre mars 2024 pour que Chrome se sente suffisamment à l'aise pour activer l'accord de clé post-quantique par défaut sur Desktop. De nombreux autres clients, de même que l'ensemble des principaux navigateurs, ont ensuite emboîté le pas à Chrome et activé cette fonctionnalité par défaut. Voici une chronologie succincte :

Juillet 2016	Première expérience post-quantique de Chrome (CECPQ)
Juin 2018	Expérience Cloudflare/Google (CECPQ2)
Octobre 2022	Cloudflare active le chiffrement post-quantique par défaut côté serveur
Novembre 2023	Chrome augmente de 10 % le déploiement de technologies post-quantiques sur Desktop
Mars 2024	Chrome active le chiffrement post-quantique par défaut sur Desktop
Août 2024	Go active le chiffrement post-quantique par défaut
Novembre 2024	Chrome active le chiffrement post-quantique par défaut sur Android et Firefox pour Desktop
Avril 2025	OpenSSL active le chiffrement post-quantique par défaut
Octobre 2025	Apple déploie le chiffrement post-quantique par défaut avec le lancement d'iOS/iPadOS/macOS 26.

Vous noterez certainement l'existence d'un décalage entre l'activation du post-quantique par Chrome sur Desktop et sur Android. Si le ML-KEM ne présente pas un impact de taille sur les performances (comme le montrent les graphiques), il n'est cependant pas négligeable non plus, notamment sur la longue traîne de connexions plus lentes, plus fréquentes sur les appareils mobiles. Sa mise en œuvre a donc nécessité davantage de réflexion.

Nous y sommes néanmoins enfin arrivés ! Plus de 50 % (et cette proportion augmente constamment !) du trafic d'origine humaine est désormais protégé contre les attaques de type « stocker maintenant/déchiffrer plus tard ». L'accord de clé post-quantique est ainsi devenu la nouvelle référence en matière de sécurité du web.

Les navigateurs représentent un aspect de l'équation, mais qu'en est-il des serveurs ?

Nous avons activé les mécanismes d'accord de clé post-quantiques côté serveur pour la quasi-totalité de nos clients depuis 2022. Google a fait de même pour la plupart de ses serveurs (sauf GCP) en 2023. De nombreux autres acteurs nous ont emboîté le pas depuis lors. Jan Schaumann publie régulièrement des analyses des 100 000 principaux domaines. Dans son article de septembre 2025, il indique que la prise en charge du chiffrement post-quantique atteint désormais les 39 %, contre 28 % six mois plus tôt. À la lecture de son étude, nous constatons non seulement le déploiement de cette prise en charge chez de grands fournisseurs de services, comme Amazon, Fastly, Squarespace, Google et Microsoft, mais également au sein d'un petit nombre croissant de serveurs auto-hébergés chez Hetzner et OVHcloud.

Nous avons parlé jusqu'ici de la portion d'Internet web accessible au public. Qu'en est-il des serveurs situés derrière un service comme Cloudflare ?

En septembre 2023, nous avons élargi cette prise en charge afin de permettre à nos clients d'activer l'accord de clé post-quantique sur les connexions entre Cloudflare et leurs serveurs d'origine. Cette prise en charge est représentée par la connexion (3) dans le schéma ci-dessous :

^{Schéma décrivant le processus de connexion typique survenant lorsqu'un visiteur demande une page non mise en cache.}

En 2023, 0,5 % seulement des serveurs d'origine prenaient en charge les mécanismes d'accord de clé post-quantiques. La situation n'a pas foncièrement évolué jusqu'en 2024. Cette année, en 2025 donc, nous constatons que les chiffres de cette prise en charge commencent à rejoindre lentement ceux du déploiement du support logiciel. Nous en sommes désormais à 3,7 %.

^{Part des serveurs d'origine prenant en charge le mécanisme d'accord de clé post-quantique X25519MLKEM768.}

Ce chiffre de 3,7 % peut sembler peu impressionnant par rapport aux 50 % et aux 39 % précédents concernant les clients et les serveurs publics, mais il ne faut néanmoins pas le sous-estimer. Les serveurs d'origine sont bien plus divers que les clients et un nombre beaucoup plus important d'acteurs doivent intervenir pour faire augmenter ce nombre. Ce chiffre a ainsi été plus que multiplié par sept. N'oublions pas que nous avons célébré le fait d'avoir atteint les 1,8 % de prise en charge client en 2024. En effet, les serveurs d'origine ne sont pas toujours faciles à mettre à niveau pour les clients. Est-ce que ce chiffre signifie que les clients risquent de passer à côté de la sécurité post-quantique ? Pas nécessairement. Vous pouvez sécuriser la connexion entre Cloudflare et votre serveur d'origine en configurant le service Cloudflare Tunnel comme complément de votre origine.

La prise en charge est certes utile, mais comme nous l'avons constaté lors des expériences sur les navigateurs, l'ossification des protocoles demeure une préoccupation majeure. Qu'en est-il pour les serveurs d'origine ? Eh bien, cela dépend.

L'activation des mécanismes d'accord de clé post-quantiques se décline de deux façons : la méthode rapide et la méthode lente, mais plus sûre. Dans les deux cas, un serveur d'origine qui ne prendrait pas en charge le post-quantique reste capable de se reposer en toute sécurité sur l'accord de clé traditionnel. Nous expliquons la situation plus en détail dans cet article de blog, mais en bref, la méthode rapide consiste à transmettre immédiatement les clés post-quantiques, tandis que la méthode plus sûre reporte cette transmission d'un aller-retour à l'aide du message HelloRetryRequest. Les principaux navigateurs utilisent tous la méthode rapide.

Nous analysons régulièrement l'ensemble des serveurs d'origine afin de contrôler ce qu'ils prennent en charge ou non. La bonne nouvelle, c'est que tous les serveurs d'origine prennent en charge la méthode sûre, mais lente. La méthode rapide ne jouit pas encore d'une adoption aussi répandue, car nous avons constaté une interruption de 0,05 % des connexions. Ce chiffre est trop élevé pour activer la méthode rapide par défaut. Nous avons activé le chiffrement post-quantique par défaut pour les serveurs d'origines (à l'aide de la méthode plus sûre) pour tous nos clients non-Enterprise. Les clients Enterprise peuvent choisir d'activer cette option.

Nous ne serons toutefois pas satisfaits tant que cette fonctionnalité ne sera pas rapide et accessible à tous. C'est pourquoi nous n'activerons automatiquement la méthode rapide de chiffrement post-quantique au sein des serveurs d'origine pour tous nos clients que si nos analyses montrent que l'opération est sûre.

Jusqu'à présent, toutes les connexions dont nous avons parlé sont établies entre Cloudflare et des parties externes. Or, de nombreuses connexions internes existent également au sein du réseau Cloudflare (la partie portant le chiffre 2 dans les deux schémas ci-dessus). En 2023, nous avons déployé beaucoup d'efforts pour mettre à niveau nos connexions internes afin qu'elles prennent en charge l'accord de clé post-quantique. Par rapport à toutes les autres initiatives post-quantiques que nous menons, il s'agit là du travail le plus important, et de loin. Nous avons demandé à chaque équipe technique de notre entreprise d'interrompre ses activités, d'évaluer les données et les connexions sécurisées par leurs produits, et de les mettre à niveau de manière à ce qu'elles prennent en charge l'accord de clé post-quantique. Dans la plupart des cas, la mise à niveau s'est révélée simple. En réalité, de nombreuses équipes étaient déjà à niveau par l'intermédiaire des mises à jour logicielles. Il faut parfois un certain temps pour comprendre que vous avez déjà atteint votre objectif ! Sur une note positive, nous n'avons également constaté aucun problème de performances ou d'ossification suite à ce déploiement.

Nous avons fait évoluer la majorité de nos connexions internes, mais une longue traîne de connexion reste à mettre à niveau et nous nous efforçons d'y parvenir. La connexion entre le client WARP et Cloudflare reste la connexion la plus importante que nous n'avons pas réussi à mettre à niveau en 2023. Nous y sommes parvenus en septembre 2025, en passant de Wireguard à QUIC.

Comme nous l'avons vu, l'accord de clé post-quantique s'est avéré des plus simples à déployer, malgré les difficultés initiales liées à l'ossification des protocoles. Dans la grande majorité des cas, ce déploiement a pris la forme d'une mise à jour logicielle sans incident. Avec un taux de déploiement de 50 % (chiffre en augmentation), il s'agit là de la nouvelle base de référence en matière de sécurité d'Internet.

Passons à la seconde migration, la plus ardue.

Intéressons-nous maintenant à la mise à niveau des signatures utilisées sur Internet.

Nous avons publié un long article consacré aux mécanismes de signature post-quantiques l'année dernière, en novembre 2024. La plupart des informations contenues dans cette étude approfondie sont toujours à jour, mais certains développements intéressants se sont produits entretemps. Les paragraphes suivants vont simplement passer en revue quelques faits marquants et mises à jour intéressantes de l'année dernière.

Commençons par évaluer les signatures post-quantiques dont nous disposons actuellement au niveau de sécurité AES-128 : le ML-DSA-44 et les deux variantes du SLH-DSA. Nous utiliserons le ML-DSA-44 comme base de référence, car il s'agit du mécanisme qui sera le plus largement répandu au départ. À titre de comparaison, nous incluons également à cet article les vénérables mécanismes Ed25519 et RSA-2048 (largement utilisés aujourd'hui), le FN-DSA-512 (qui sera bientôt normalisé) et un échantillon de neuf mécanismes de signature TLS prometteurs issus du tremplin signatures.

^{Comparaison de divers mécanismes de signature au niveau de sécurité AES-128. Les temps processeur varient considérablement selon la plateforme et les contraintes de mise en œuvre. Ils ne sont donnés ici qu'à titre d'indication approximative. ⚠️ Temps de signature FN-DSA en cas d'utilisation du modèle arithmétique à virgule flottante rapide, mais dangereux. Voir l'avertissement ci-dessous. ⚠️ Le processus de signature SQISign n'est pas sécurisé du point de vue des canaux temporels auxiliaires (timing side-channels).}

Il apparaît immédiatement qu'aucun des mécanismes de signature post-quantiques ne peut espérer s'imposer comme un remplacement direct de l'Ed25519 (un schéma comparable au ECDSA P-256), car les signatures sont pour la plupart beaucoup trop volumineuses. Issus du tremplin, les mécanismes SQISign, MAYO, SNOVA et UOV font exception à la règle, mais se révèlent loin d'être parfaits. Le MAYO, le SNOVA et l'UOV utilisent des clés publiques de grande taille, tandis que le SQISign nécessite une forte puissance de calcul.

Pour anticiper un peu : le meilleur mécanisme issu du premier concours semble être le FN-DSA-512. Les signatures et la clé publique du FN-DSA-512 ne totalisent ensemble que 1 563 octets, pour un temps de signature assez raisonnable. Le FN-DSA présente toutefois un talon d'Achille : il nécessite l'emploi du modèle arithmétique rapide à virgule flottante pour afficher des performances acceptables en termes de durée du processus de signature. Le temps de signature est environ 20 fois plus lent sans ce modèle. Toutefois, la vitesse ne fait pas tout, car le modèle arithmétique à virgule flottante doit s'exécuter en temps constant. Dans le cas contraire, la clé privée FN-DSA peut être récupérée en mesurant le temps nécessaire à la création de la signature. La rédaction d'implémentations FN-DSA sécurisées s'est en outre avérée assez difficile. Or, ce problème rend le FN-DSA dangereux lorsque les signatures sont générées à la volée, comme lors d'une négociation TLS. Il est important de souligner que ce problème n'affecte que la signature. La vérification FN-DSA ne nécessite pas l'emploi du modèle arithmétique à virgule flottante (il n'y aurait de toute façon aucune clé privée à divulguer pendant la vérification).

Le principal inconvénient de la migration d'Internet vers les signatures post-quantiques réside dans le grand nombre de signatures impliquées, même au sein d'une seule connexion. Le simple fait de se connecter à notre site web pour la première fois implique l'envoi de cinq signatures et deux clés publiques de notre part.

La majorité de ces signatures concernent la chaîne de certificats : l'autorité de certification signe le certificat intermédiaire, qui signe le certificat Leaf, qui à son tour signe la transcription TLS afin de prouver l'authenticité du serveur. Si vous comptez bien, il nous manque toujours deux signatures.

Elles interviennent sur les SCT (Signed Certificate Timestamps, horodatage de signature numérique) nécessaires à la transparence des certificats. La transparence des certificats (CT, Certificate Transparency) constitue un élément clé, mais moins connu, du Web PKI (Public Key Infrastructure, l'infrastructure à clés publiques du web), c'est-à-dire l'écosystème qui sécurise les connexions des navigateurs. Cette opération a pour objectif d'enregistrer publiquement chaque certificat émis afin que les erreurs d'émissions puissent être détectées a posteriori. Il s'agit là du système qui sous-tend le fonctionnement de crt.sh et de Cloudflare Radar. Ce système a encore récemment apporté la preuve de sa valeur en faisant apparaître un certificat non autorisé pour le résolveur 1.1.1.1.

Le processus de transparence des certificats repose sur le fait de demander à des parties indépendantes d'exécuter des journaux CT. Avant d'émettre un certificat, une autorité de certification doit d'abord l'envoyer à au moins deux journaux CT différents. Un SCT constitue la signature d'un journal CT. Il sert de preuve, de reçu, que le certificat a bien été enregistré.

Il convient de souligner l'importance de deux aspects de l'utilisation d'une signature : l'inclusion ou non de la clé publique au sein de la signature et le fait que la signature soit disponible en ligne ou hors ligne.

La clé publique n'est pas transmise lors de la négociation pour les SCT et la signature de la racine sur le certificat intermédiaire. Le MAYO, le SNOVA ou l'UOV seraient ainsi particulièrement bien adaptés aux systèmes qui recherchent un mécanisme reposant sur de petites signatures, mais des clés publiques de plus grande taille. La clé publique est incluse dans les autres signatures, pour lesquelles il est plus important de réduire la taille combinée de la clé publique et de la signature.

La signature de négociation est la seule signature à être créée en ligne. Toutes les autres signatures le sont à l'avance.  La signature de négociation est créée et vérifiée une seule fois, tandis que les autres signatures sont généralement vérifiées de nombreuses fois, par différents clients. Dans le cas de la signature de négociation, il est ainsi plus avantageux d'équilibrer les temps de signature et de vérification, qui se situent tous deux dans le hot path (le déroulement critique). Pour les autres signatures, il est préférable de disposer d'un temps de vérification plus rapide, même si cela implique un processus total de signature plus lent. C'est là l'un des avantages dont le RSA bénéficie encore aujourd'hui par rapport aux signatures basées sur les courbes elliptiques.

L'association de différents mécanismes de signature peut constituer un casse-tête amusant, mais cette approche comporte également certains inconvénients. Premièrement, l'utilisation de plusieurs mécanismes différents augmente la surface d'attaque, car la présence d'une vulnérabilité algorithmique ou liée à la mise en œuvre au sein d'un seul d'entre eux compromet l'ensemble. En outre, l'écosystème dans son ensemble doit déployer et optimiser plusieurs algorithmes, ce qui peut représenter une charge significative.

Quelles combinaisons raisonnables pouvons-nous donc essayer ?

Les projets de normes disponibles à l'heure actuelle ne nous laissent pas beaucoup d'options.

Si nous nous contentons de passer au ML-DSA-44 pour l'ensemble des signatures, nous ajoutons 15 Ko à la quantité de données qui doivent être transmises du serveur au client lors de la négociation TLS. Est-ce là une quantité importante de données ? Probablement. Nous répondrons à cette question plus tard.

Si nous attendons un peu et que nous remplaçons l'ensemble des mécanismes par le FN-DSA-512 (sauf pour la signature de négociation), nous n'ajoutons que 7 ko. C'est mieux, mais au risque de me répéter, je dois rappeler que la mise en œuvre du FN-DSA-512 de manière sécurisée se révèle des plus difficiles sans canaux temporels auxiliaires. Il y a donc de fortes chances pour que nous nous tirions une balle dans le pied si nous ne faisons pas attention. Les signatures basées sur le hachage et persistantes (stateful) constituent un autre moyen de se tirer une balle dans le pied aujourd'hui, comme nous l'expliquons ici. Dans l'ensemble, le FN-DSA-512 et les signatures persistantes basées sur le hachage sont tentants de par leur promesse similaire et claire d'avantages en termes de performances par rapport au ML-DSA-44, mais elles se révèlent difficiles à utiliser en toute sécurité.

De nouveaux mécanismes de signature prometteurs ont été soumis à l'occasion du tremplin signatures du NIST.

Si l'on se base uniquement sur la taille, le SQISign I ressort clairement vainqueur, en parvenant même à dépasser le RSA-2048. Malheureusement, la puissance de calcul nécessaire au processus de signature et (surtout) au processus de vérification s'avère trop importante. Le mécanisme SQISign est dans une position moins favorable que le FN-DSA en ce qui concerne la sécurité des déploiements. Il est très compliqué et la marche à suivre pour procéder à la signature en temps constant n'est pas claire. Le SQISign peut s'avérer utile pour les applications de niche, mais de gros efforts doivent être faits sur le temps de vérification si l'on vise l'adoption généralisée, même si le résultat implique l'utilisation d'une signature de plus grande taille. Des progrès considérables ont été réalisés ces dernières années en termes de temps de vérification, de simplification de l'algorithme et de sécurité du déploiement pour (les variantes de) SQISign. Nous ne sommes pas encore au bout de nos peines, mais l'écart s'est fortement réduit. Bien plus que ce à quoi nous nous attendions. Si le rythme des améliorations se maintient, un futur SQISign pourrait bien s'avérer viable pour le TLS.

L'un de ses prétendants les plus prudents est le mécanisme UOV (Unbalanced Oil and Vinegar, mélange non-équilibré d'huile et de vinaigre). Cet ancien mécanisme multivarié utilise une clé publique de grande taille (66,5 Ko), mais de petites signatures (96 octets). De nombreuses tentatives de structuration des clés publiques UOV ont été initiées au fil des décennies afin d'obtenir un meilleur équilibre entre la taille de la clé publique et celle de la signature. Malheureusement, bon nombre de ces mécanismes prétendument multivariés et structurés (comme Rainbow et GeMMS) ont été invalidés de manière spectaculaire « en un week-end, avec un simple ordinateur portable ». Le MAYO et le SNOVA (que nous examinerons dans un instant) sont les dernières tentatives en termes de mécanismes multivariés et structurés. En soi, l'UOV s'en est sorti globalement indemne. Fait surprenant, Lars Ran a découvert une toute nouvelle attaque « wedges » (une attaque impliquant le produit extérieur) contre l'UOV en 2025. Si cette attaque n'affecte pas énormément l'UOV en définitive, les mécanismes SNOVA et MAYO sont plus durement touchés quant à eux. Le point qui rend cette attaque si remarquable, c'est qu'elle repose sur une idée relativement simple. Il est même surprenant qu'elle n'ait pas été découverte plus tôt. Pour en revenir aux performances, si nous associons l'UOV pour la racine et les SCT au ML-DSA-44 pour les autres signatures, nous n'obtenons qu'une quantité de données de 10 Ko, soit un résultat proche du FN-DSA-512.

Passons maintenant à l'événement que nous attendons tous :

Si l'on examine le classement actuel, le MAYO et le SNOVA (plus particulièrement) affichent d'excellentes performances. Le SNOVA et le MAYO étaient plus proches l'année dernière en termes de performances, mais leurs résultats ont fortement divergé depuis.

Le MAYO a été conçu par le cryptographe qui a invalidé le Rainbow. La sécurité de ce mécanisme nécessite une analyse rigoureuse, du fait de sa nature multivariée et structurée, mais son utilité demeure particulièrement séduisante (en partant du principe qu'il ne sera pas délégitimisé dans un avenir plus ou moins proche). Le MAYO permet un compromis précis entre la taille de la signature et celle de la clé publique. Pour rester simple, les auteurs en ont proposé deux variantes concrètes lors de sa soumission : le MAYO_one, équilibré du point de vue de la taille de la signature (454 octets) et de la clé publique (1,4 Ko), et le MAYO_two, qui présente une signature de 216 octets, tout en conservant une clé publique de taille gérable, avec 4,3 Ko. Le temps de vérification est excellent, tandis que le temps de signature se montre légèrement plus lent que pour l'ECDSA, mais bien meilleur qu'avec le RSA. En associant les deux variantes de manière évidente, nous ne totalisons que 4,3 Ko. Ces chiffres se révèlent légèrement supérieurs à ceux de l'année dernière, car le MAYO a de nouveau légèrement ajusté ses paramètres afin de tenir compte des attaques récemment identifiées.

Le SNOVA a été plus sévèrement touché par les attaques que le MAYO pendant le concours. La réponse de ses auteurs s'est montrée plus énergique : plutôt que de se contenter d'ajuster les paramètres pour s'adapter à la situation, l'équipe a également apporté des modifications importantes aux rouages internes du mécanisme afin de contrer les attaques et d'améliorer les performances par la même occasion. En associant le SNOVA_(37,17,16,2) et le SNOVA_(24,5,23,4) de la manière la plus évidente, nous ne totalisons une augmentation de volume que de 2,1 Ko seulement.

Un antagonisme est ainsi en train de se dessiner entre le SNOVA, risqué mais de taille bien plus petite, et le MAYO, prudent mais plus lent. Sur un plan d'ensemble, ces mécanismes proposent tous deux des performances très louables et se révèlent tous deux trop risqués pour faire l'objet d'un déploiement à l'heure actuelle. À titre d'exemple, la nouvelle attaque « wedges » identifiée par Ran montre que le domaine de la cryptanalyse multivariée nous réserve encore bien des surprises. De même, cette approche nécessite davantage d'attention et de temps. Il est trop tôt pour désigner un vainqueur entre le SNOVA et le MAYO : laissons-les continuer à s'affronter encore un peu. Il est peu probable que ces mécanismes soient normalisés avant 2029, quand bien même ils s'avéraient finalement sécurisés. Nous ne pouvons par conséquent pas nous reposer sur ces deniers pour la migration initiale vers l'authentification post-quantique.

En y repensant avec un peu de recul, ce chiffre de 15 ko pour le ML-DSA-44 est-il vraiment aussi mauvais ?

En moyenne, près de 18 millions de connexions TLS sont établies avec Cloudflare chaque seconde. La mise à niveau de chacune d'elles vers le ML-DSA nécessiterait 2,1 Tb/s, soit 0,5 % de notre capacité réseau totale à l'heure actuelle. Aucun problème pour le moment donc. Toute la question consiste à savoir de quelle manière ces octets supplémentaires affectent les performances.

Le passage au ML-DSA-44 demanderait 15 Ko supplémentaires. C'est beaucoup par rapport au volume d'une négociation typique d'aujourd'hui, mais peu comparé au JavaScript et aux images diffusées sur de nombreuses pages web. L'idée à retenir ici est que le changement que nous devons apporter affectera toutes les connexions TLS, qu'elle soit établie pour faire fonctionner un site web exagérément lesté ou procéder à un appel d'API prioritaire, pour lequel le temps de réponse constitue une notion critique. De même, l'idée n'est pas que nous allons devoir attendre un peu plus longtemps. Ce volume de données supplémentaire peut faire toute la différence entre le chargement d'une page et l'expiration du délai de connexion en cas de réception irrégulière du fait d'un réseau mobile sporadique. (Petite info en aparté, tant que nous sommes en train de parler de lest excessif : beaucoup d'applications procèdent à un nombre étonnamment élevé de négociations TLS).

Tout comme pour les mécanismes d'accord de clé, nous ne nous soucions pas uniquement des performances : nous souhaitons également que la connexion puisse être établie en premier lieu. En 2021, nous avons conduit une expérience visant à agrandir artificiellement la chaîne de certificats afin de simuler l'utilisation de certificats post-quantiques de plus grande taille. Nous en résumons le résultat ici. L'un des enseignements que nous devons retirer de cette expérience, c'est que certains clients ou boîtiers intermédiaires n'apprécient pas les chaînes de certificats d'une taille supérieure à 10 Ko. Ce point s'avère problématique pour une stratégie de migration à certificat unique. Selon cette approche, le serveur installe un unique certificat traditionnel contenant un certificat post-quantique distinct au sein d'une extension définie comme non critique. Un client qui ne prendrait pas en charge les certificats post-quantiques ignorera l'extension. Selon cette approche, toujours, l'installation d'un unique certificat entraînera immédiatement l'émergence de problèmes de compatibilité pour tous les clients. Cette solution est donc vouée à l'échec. Nous constatons également une forte baisse des performances à partir de 10 Ko du fait de la fenêtre de congestion initiale.

Un volume de 9 Ko serait-il trop élevé également ? Le temps nécessaire à la négociation TLS serait ralenti d'environ 15 %. Nous avons estimé que cette deuxième solution était envisageable, mais loin d'être parfaite. En effet, ce type de ralentissement est perceptible et pourrait inciter les entreprises à repousser le déploiement de certificats post-quantiques jusqu'à ce qu'il soit tard pour y procéder en toute sécurité.

Chrome est plus prudent et s'est fixé un objectif de 10 % pour la régression maximale du temps nécessaire à la négociation TLS. Ses équipes rapportent que le déploiement de l'accord de clé post-quantique a déjà entraîné un ralentissement de 4 % du temps nécessaire à la négociation TLS, en raison des 1,1 Ko de données supplémentaires à transmettre du serveur vers le client et des 1,2 Ko à transmettre du client vers le serveur. Proportionnellement, ce ralentissement se révèle plus important que les 15 % que nous avons observés pour les 9 Ko. Ce phénomène pourrait toutefois s'expliquer par le fait que le débit montant (importation) est plus lent que le débit descendant (téléchargement). 

L'accent mis sur le temps nécessaire à la négociation TLS a rencontré certaines résistances. L'un des arguments avancés est que la possibilité de reprendre une session élimine la nécessité de renvoyer les certificats. Deuxième argument : la quantité de données nécessaires pour naviguer sur un site web typique dépasse de loin les octets supplémentaires requis par les certificats post-quantiques. Cette publication de 2024, dans laquelle des chercheurs d'Amazon ont simulé l'impact des certificats post-quantiques de grande taille sur les connexions TLS présentant un volume élevé de données, en constitue un bon exemple. Ils soutiennent que plusieurs requêtes et des centaines de kilo-octets font l'objet d'un transfert lors d'une connexion habituelle et que le ralentissement de la négociation TLS apparaît dès lors comme marginal.

La reprise de session et la transmission de centaines de kilo-octets au cours d'une connexion sont-elles néanmoins des opérations typiques ? Nous souhaiterions vous faire part de ce que nous observons. À cet effet, nous nous concentrerons sur les connexions QUIC, qui sont généralement initiées par des navigateurs ou des clients apparentés à des navigateurs. 27 % des connexions QUIC établies avec Cloudflare et sur lesquelles transite au moins une requête HTTP sont des reprises. C'est-à-dire qu'elles réutilisent les informations de clé d'une connexion TLS précédente afin d'éviter de devoir transmettre à nouveau les certificats. Le nombre médian d'octets transférés d'un serveur vers un client sur une reprise de connexion QUIC est de 4,4 Ko, tandis que la moyenne est de 259 Ko. Le chiffre médian est de 8,1 ko et la moyenne de 583 ko pour les connexions qui ne sont pas des reprises. La forte différence entre le chiffre médian et la moyenne indique que cette dernière est faussée par une faible proportion de connexions très consommatrices de données. En réalité, seuls 15,5 % de l'ensemble des connexions QUIC transfèrent plus que 100 Ko de données.

La chaîne de certificats médiane actuelle (avec compression) est de 3,2 Ko. Ce chiffre signifie que près de 40 % des données transférées du serveur vers le client sur plus de la moitié des connexions QUIC non reprises sont uniquement réservées aux certificats. Or, ce problème ne fait qu'empirer avec les algorithmes post-quantiques. Pour la majeure partie des connexions QUIC, l'utilisation du ML-DSA-44 en remplacement des mécanismes de signature classiques doublerait (au minimum) le nombre d'octets transmis sur l'ensemble du cycle de vie de la connexion.

Le fait que la grande majorité des données transférées au cours d'une connexion typique soient uniquement destinées aux certificats post-quantiques constitue assurément un problème. Il ne s'agit toutefois que de l'arbre qui cache la forêt par rapport à ce qui est réellement important : l'impact sur les indicateurs pertinents pour l'utilisateur final, comme l'expérience de navigation (p. ex. le Largest Contentful Paint ou LCP, c'est-à-dire le temps nécessaire au rendu du plus grand élément de contenu visible) et la quantité de données que ces certificats consomment sur le forfait de données mensuel de l'utilisateur. Nous allons poursuivre nos investigations afin de mieux comprendre les répercussions de cette situation.

Le chemin à suivre pour procéder à la migration de l'Internet vers l'authentification post-quantique est beaucoup moins clair que pour l'accord de clé. Nous nous attendons à ce que la grande majorité des entreprises n'active pas l'authentification post-quantique tant que nous ne parviendrons pas à améliorer sensiblement les performances de manière à ce qu'elles soient similaires à celles des mécanismes d'authentification utilisés d'aujourd'hui. Le fait de reporter l'activation de l'authentification post-quantique jusqu'à l'approche du Q-Day comporte un risque réel : ne pas être en mesure de déceler les problèmes avant qu'il ne soit trop tard pour les résoudre. Nous devons donc rendre l'authentification post-quantique suffisamment performante pour permettre son activation par défaut. Il s'agit là d'une priorité des plus essentielles.

Nous sommes actuellement en train d'explorer différentes idées pour réduire le nombre de signatures, que nous vous présentons ici par ordre d'ambition croissant : l'abandon des certificats intermédiaires, le KEMTLS et les certificats Merkle Tree. Nous avons étudié ces aspects en détail l'année dernière. Nous avons justement réalisé le plus de progrès sur les derniers de cette liste : les certificats Merkle Tree (MTC, Merkle Tree Certificates). Selon cette proposition (et dans le cas le plus fréquent), toutes les signatures, à l'exception de la signature de négociation, sont remplacées par une courte preuve de moins de 800 octets, basée sur l'arbre de Merkle. Cette approche pourrait bien permettre la mise en place d'un mécanisme d'authentification post-quantique qui se révélerait en fait plus rapide que les certificats traditionnels utilisés actuellement ! Nous allons procéder à des essais de manière conjointe avec Chrome d'ici la fin de l'année. Vous trouverez toutes les informations à ce sujet dans cet article de blog.

L'article présent, malgré sa longueur, n'a fait qu'effleurer la question de la migration TLS. De même, nous n'avons pas abordé le protocole TLS de manière exhaustive, car nous n'avons pas évoqué l'Encrypted ClientHello (nous ne l'avons cependant pas oublié). En dépit de son importance, le TLS n'est pas le seul protocole essentiel à la sécurité d'Internet. Nous souhaitons ainsi mentionner brièvement quelques autres difficultés dans les lignes qui suivent, mais nous ne pouvons entrer dans les détails. Le DNSSEC, responsable de la sécurisation de la résolution des noms de domaine, constitue l'une de ces problématiques particulières.

Si les accords de clé et les signatures sont effectivement les primitives cryptographiques les plus utilisées, nous avons assisté ces dernières années à l'adoption de modes de chiffrement plus ésotériques conçus pour servir des scénarios d'utilisation plus avancés, comme les jetons non liables avec le Privacy Pass/PAT, les identifiants anonymes et le chiffrement basé sur les attributs pour n'en citer que quelques-uns. Aucune alternative post-quantique pratique connue n'existe encore pour la plupart de ces mécanismes cryptographiques avancés. À notre grande joie, des avancées considérables ont toutefois été réalisées dans le domaine des identifiants anonymes post-quantiques.

En résumé, deux axes de migration post-quantique sont principalement à surveiller : les mécanismes d'accord de clé et les certificats.

Nous vous recommandons de passer à l'accord de clé post-quantique pour contrer les attaques de type « stocker maintenant, déchiffrer plus tard ». Cette opération ne nécessite qu'une simple mise à jour logicielle des deux côtés. Dans un contexte d'adoption rapide du X25519MLKEM768 au sein des logiciels et des services (nous tenons une liste ici), cette simplicité implique que vous pourriez déjà être protégé contre l'approche « stocker maintenant, déchiffrer plus tard » ! Vous pouvez également vous rendre sur Cloudflare Radar pour vérifier si votre navigateur prend en charge le X25519MLKEM768. Si vous utilisez Firefox, une extension existe pour contrôler la prise en charge des sites web sur lesquels vous vous rendez. Vous pouvez vérifier si votre site web prend en charge ce mécanisme ici et utiliser Wireshark pour vérifier cette prise en charge sur vos connexions.

Il ne s'agit là que des vérifications ponctuelles. Pour vous lancer dans un processus de migration approprié, vous devrez déterminer à quel endroit utiliser le chiffrement. C'est là un défi de taille, car la plupart des entreprises ont du mal à suivre l'ensemble des logiciels, des services et des fournisseurs externes qu'elles utilisent en premier lieu. Certains systèmes seront plus difficiles à mettre à niveau ou disposeront de dépendances externes, mais l'opération devrait globalement s'avérer simple. Pour tout dire, dans de nombreux cas, vous consacrerez beaucoup de temps à découvrir que la migration a déjà été effectuée.

Comme l'essentiel du travail consiste à déterminer ce qui reste à faire, il est peut-être tentant de diviser cette tâche en commençant par cette première étape : la production d'un inventaire détaillé (que l'on appelle également la nomenclature cryptographique, ou CBOM pour Cryptographic Bill Of Materials). Ne laissez pas cet inventaire devenir un objectif en soi : veillez à bien rester concentrés sur l'essentiel. Dans la plupart des cas, l'opération sera des plus simples : si vous avez déterminé la procédure de migration dans un cas précis, n'attendez pas et ne changez pas de contexte, procédez directement à la migration. Le processus n'en sera pas pour autant rapide : c'est un marathon, pas un sprint, mais vous seriez surpris de voir tout le chemin que vous pouvez parcourir en vous lançant dès maintenant.

Passons aux certificats. À l'heure où nous écrivons ces lignes, en octobre 2025, les normes finales régissant les certificats post-quantiques ne sont pas encore définies. Espérons que cette finalisation ne demande pas trop de temps. Il vous reste néanmoins des quantités de choses à faire dès aujourd'hui pour vous préparer au déploiement des certificats post-quantiques afin de vous assurer que vous ne le regretterez en aucun point. Maintenir vos logiciels à jour. Automatiser l'émission de certificats. Vous assurer d'être en mesure d'installer plusieurs certificats.

Aucune raison d'attendre si l'ossification des protocoles vous inquiète : les normes post-quantiques finales ne seront pas très différentes de leurs versions de projet. Vous pouvez commencer à tester les versions préliminaires dès aujourd'hui (ou procéder à des tests à l'aide de faux certificats de grande taille).

Le processus de migration post-quantique est tout à fait unique. En général, l'invalidation d'une méthode de chiffrement arrive soit soudainement, soit de manière progressive, ce qui permet d'ignorer facilement la mauvaise nouvelle pendant un certain temps. Dans les deux cas, les migrations finissent par être précipitées. Concernant la menace quantique, nous savons avec certitude que nous devrons remplacer une grande partie de nos techniques de chiffrement, mais nous avons également un peu de temps devant nous. Plutôt qu'une corvée, nous vous invitons donc à y voir une opportunité : celle d'assurer la maintenance de nombreux systèmes rarement utilisés. C'est l'occasion rêvée de repenser vos choix passés, au lieu de vous contenter de déployer des correctifs à chaud.

Du moins, si vous vous lancez dans l'aventure dès aujourd'hui. Bonne chance pour votre migration et n'hésitez pas à nous contacter sur ask-research@cloudflare.com si vous rencontrez des problèmes.