Post-Quantum TLS 1.3: Which Hybrid KEM Configuration Minimizes Handshake Overhead in OpenSSL?

TLS 1.3 migre vers l'échange de clés post-quantique car Diffie-Hellman classique et X25519 ne résisteront pas à un grand ordinateur quantique. Le NIST a choisi ML-KEM comme mécanisme d'encapsulation de clé post-quantique [9]. L'échange de clés et l'authentification post-quantiques avec ML-KEM et ML-DSA affecteront les performances de TLS 1.3 sur le Web et dans d'autres applications [9]. Les études jusqu'à présent se sont concentrées sur le surcoût de ces algorithmes résistants aux quantiques sur le temps jusqu'au premier octet de TLS, c'est-à-dire le temps de prise de contact [9]. Cette orientation a du sens pour le coût d'établissement de la connexion, mais elle laisse la taille du code, une deuxième préoccupation nommée directement dans la question de recherche, presque totalement non abordée par la littérature de mesure rassemblée ici.

Les données de déploiement montrent que la transition est déjà en cours mais incomplète. Une étude de mesure de 2026 a révélé que 49.3% des domaines prennent en charge des mécanismes hybrides d'échange de clés post-quantiques tels que MLKEM768 avec X25519, tandis que 50.7% des domaines continuent d'utiliser un échange de clés classique [14]. La même étude a trouvé 0% d'adoption de certificats hybrides post-quantiques, laissant la couche d'authentification vulnérable aux attaques activées par les quantiques telles que la falsification de certificats [14]. Elle a également trouvé que 15.70% des domaines, en particulier dans des secteurs critiques comme la banque et le gouvernement, reposent encore sur TLS 1.2 [14]. Cet état mixte explique pourquoi les développeurs ont besoin de chiffres de performance concrets maintenant, et non après la fin de la migration.

La motivation de sécurité est quantifiable. Le matériel de clé symétrique à 128 bits de sécurité classique fournit environ 64 bits de sécurité effective contre un attaquant quantique [14]. Ce division par deux est la raison pour laquelle la migration KEM est traitée comme urgente plutôt qu'optionnelle, et elle cadre pourquoi les compromis de latence et de taille des configurations KEM spécifiques comptent opérationnellement, pas seulement académiquement.

La question de recherche demande spécifiquement à propos d'OpenSSL 3.4+ et des configurations nommées telles que X25519Kyber768 et X25519MLKEM512. Les affirmations disponibles décrivent des expériences sur OpenSSL 3.x intégré avec liboqs [1] [8] et sur des benchmarks multiplateformes de familles PQC connexes [12], mais aucune des sources ne lie ses mesures à la version exacte OpenSSL 3.4+ ou à la métrique de taille de code nommée dans la question. Un développeur devrait lire le reste de cette note comme une réponse à la moitié latence de la question, avec une lacune explicite signalée sur la moitié taille du code.

Dit clairement et une fois, d'entrée : aucune affirmation vérifiée ne relie l'avantage de taille de paquet de ML-KEM-512, ou la performance d'une configuration KEM, à la taille du code. Chaque affirmation discutant de l'avantage de ML-KEM-512 ne parle que de la taille du paquet et de la latence de la prise de contact sous stress réseau, jamais de la taille du code compilé ou lié, de l'empreinte binaire ou de la taille de la bibliothèque [1]. Aucune affirmation ne compare la taille du code entre ML-KEM-512, ML-KEM-768, Kyber768 ou une combinaison hybride. Un lecteur qui a besoin d'une réponse sur la taille du code devrait traiter cette note comme silencieuse sur cette dimension ; rien ici n'implique qu'un avantage de taille de paquet se traduit par un avantage de taille de code, car aucune source ne fait cette connexion.

Cela importe pour les déploiements embarqués et contraints, où la taille du code est souvent la contrainte déterminante plutôt que la latence. Puisque la littérature examinée ici ne la mesure pas, toute décision d'approvisionnement ou d'ingénierie qui dépend de la taille du code ne peut être réglée par ces seules affirmations. Le reste de cette note traite donc la latence comme la moitié répondable de la question et la taille du code comme une question ouverte et non abordée.

ML-KEM est l'un des choix d'algorithmes post-quantiques du NIST pour l'échange de clés, aux côtés de ML-DSA pour l'authentification [9]. Les expériences les plus pertinentes pour les performances d'OpenSSL évaluent les algorithmes ML-KEM directement et aussi une configuration hybride, X25519+ML-KEM-768, combinant l'échange sur courbe elliptique classique X25519 avec le mécanisme post-quantique ML-KEM-768 [1]. Cette conception hybride est courante dans le déploiement : les mécanismes hybrides d'échange de clés post-quantiques observés dans la nature, tels que MLKEM768 avec X25519, suivent le même motif d'association d'une primitive classique et d'une primitive post-quantique dans une seule négociation [14].

D'autres travaux dans ce domaine étudient des familles KEM connexes mais distinctes. Une étude examine l'impact de l'incorporation de KEM post-quantiques, spécifiquement les normes CRYSTALS-Kyber et HQC, ainsi que le candidat standard BIKE, dans la prise de contact TLS 1.3 [8]. Une autre présente ce qu'elle appelle l'évaluation empirique multiplateforme la plus étendue à ce jour des algorithmes PQC sélectionnés par le NIST, incluant CRYSTALS-Kyber et NTRU pour les KEM, avec BIKE comme alternative basée sur les codes, et CRYSTALS-Dilithium et Falcon pour les signatures [12]. Ceux-ci élargissent le tableau au-delà de ML-KEM seul mais ne rapportent pas de chiffres pour les étiquettes exactes X25519MLKEM512 ou X25519Kyber768 nommées dans la question ; un développeur qui fait le lien entre ces familles et les noms de groupes OpenSSL doit le faire avec précaution, car les affirmations ici ne disent pas que Kyber et ML-KEM sont interchangeables ou identiques.

Le côté signature de TLS 1.3 est un mécanisme distinct de l'échange de clés mais partage la même pression de migration. Dilithium 2 et Falcon 512 surpassent RSA 4096 en durée de temps de prise de contact TLS [13]. C'est un contexte utile pour un développeur assemblant une pile TLS 1.3 entièrement post-quantique, puisque les choix d'algorithmes d'échange de clés et de signature contribuent tous deux au coût total de la prise de contact, mais c'est un résultat distinct des comparaisons KEM qui sont l'objet de cette note.

La méthode la plus détaillée pour les nombres pertinents pour OpenSSL est l'étude ARM64. Les expériences ont été réalisées en utilisant OpenSSL 3.x intégré avec liboqs [1]. La configuration hybride X25519+ML-KEM-768 était l'une des configurations évaluées [1]. 100 itérations ont été effectuées pour chaque configuration [1]. Cinq scénarios réseau ont été utilisés : boucle locale, LAN (10 ms RTT), WAN (50 ms RTT), et des taux de perte de paquets de 1% et 5% [1]. Lu comme cinq conditions distinctes, boucle locale, LAN, WAN, perte 1%, et perte 5%, cela correspond au nombre de cinq indiqué ; un développeur reproduisant la configuration devrait la traiter de cette manière plutôt que comme quatre scénarios.

Une étude connexe mais distincte sur un terrain similaire examine Kyber, HQC et BIKE dans TLS 1.3, et a mené une évaluation expérimentale complète mesurant la latence de la prise de contact sous des conditions réseau émulées avec des probabilités de perte de paquets variables [8]. Ceci est méthodologiquement parallèle à la conception de stress réseau de l'étude ARM64 mais couvre une famille KEM différente, donc ses chiffres ne doivent pas être fusionnés avec les chiffres ML-KEM sans précaution.

Un troisième effort de benchmarking plus large a mesuré la latence de calcul, l'utilisation de la mémoire, les tailles de clés et le surcoût protocolaire à travers plusieurs niveaux de sécurité, Niveaux 1, 3 et 5 du NIST, dans trois environnements matériels distincts et diverses conditions réseau [12]. C'est la seule affirmation de l'ensemble qui nomme les tailles de clés et l'utilisation de la mémoire comme variables mesurées, ce qui est proche mais encore distinct de la taille du code ; elle ne rapporte pas de chiffre de taille de code pour aucune configuration OpenSSL, donc elle ne comble pas la lacune signalée ci-dessus.

Une quatrième étude adopte un angle différent, décomposant la prise de contact TLS en étapes et mesurant les tailles d'effet plutôt que les temps bruts. Cette approche par couches lui permet d'isoler où dans la prise de contact un choix KEM importe réellement, plutôt que de traiter la prise de contact comme une seule mesure agrégée ; sa conclusion centrale est discutée une fois, en entier, dans la section suivante.

Les chiffres de latence principaux proviennent de l'étude ARM64. Les algorithmes ML-KEM introduisent un surcoût de calcul négligeable par rapport au X25519 classique sous des conditions de faible latence [1]. Les temps de prise de contact 1-RTT en état de base pour les algorithmes ML-KEM vont de 11.3 à 13.3 ms [1] ; c'est la seule fourchette faisant autorité pour le timing en état de base dans cette note, référencée depuis d'autres sections plutôt que reformulée. Sous perte de paquets, l'écart se creuse : ML-KEM a atteint 180 ms avec 5% de perte de paquets, tandis que X25519 a atteint 281 ms [1], donc au taux de perte le plus élevé testé, ML-KEM était plus rapide en termes absolus, pas seulement comparable. Les temps de redémarrage de session ont constamment réduit la latence de la prise de contact pour tous les algorithmes testés [1], ce qui signifie que les connexions reprises étaient plus rapides que les prises de contact 1-RTT fraîches dans l'ensemble, indépendamment du KEM utilisé.

Dans cette étude ARM64, ML-KEM-512 a montré les meilleures performances, en particulier en raison de sa petite taille de paquet [1]. C'est la seule affirmation de l'ensemble qui classe les configurations les unes par rapport aux autres sur un mécanisme nommé, et c'est la plus proche que les preuves parviennent à répondre directement à la moitié latence de la question de recherche.

Une analyse séparée, par couches, décompose la prise de contact TLS 1.3 en étapes au lieu de la traiter comme un seul nombre, et c'est le qualificatif le plus important sur les résultats ARM64 ci-dessus. Sa conclusion centrale, énoncée une fois ici et référencée plutôt que répétée ailleurs dans cette note : l'échange de la prise de contact TLS, l'étape du ClientHello à Finished, est effectivement neutre sur le plan algorithmique, avec toutes les configurations testées, classiques, hybrides et ML-KEM pur, montrant des tailles d'effet négligeables, le Δ de Glass en dessous de 0.2 à 0.33 [4]. En accord avec cela, aucune pénalité ou avantage pratiquement significatif attribuable à l'algorithme d'échange de clés n'a été trouvé dans l'échange de la prise de contact TLS [4]. Au lieu de cela, le coût sensible à l'algorithme est isolé dans la construction du ClientHello spécifiquement [4], et non dans l'échange aller-retour dans son ensemble.

Cela recadre les chiffres ARM64 plutôt que de les contredire. La fourchette en état de base et les chiffres de perte de paquets cités ci-dessus [1] décrivent le temps brut de prise de contact mesuré à l'horloge murale sous stress réseau ; la conclusion de taille d'effet négligeable de l'étude par couches [4] décrit la taille statistique de la différence attribuable à l'algorithme au sein de l'étape d'échange de la prise de contact, sous des conditions et métriques probablement différentes. Les deux ne mesurent pas la même quantité, donc un développeur ne devrait pas lire l'une comme renversant l'autre ; plutôt, les chiffres ARM64 montrent ce qui se passe sous des conditions réseau défavorables spécifiquement, tandis que l'analyse par couches montre qu'en moyenne sur les configurations, l'étape d'échange elle-même porte peu de coût attribuable à l'algorithme, avec la véritable sensibilité en amont dans la construction du ClientHello.

Mis ensemble, une lecture pratique est : si la cible de déploiement est dominée par le stress réseau, la perte de paquets et le RTT, les chiffres ARM64 sont les pertinents et ML-KEM-512 est rapporté comme le meilleur performeur là [1]. Si la cible de déploiement est un réseau stable à faible perte, la conclusion de l'étude par couches suggère que le choix parmi les configurations testées ne produira pas, à lui seul, une différence de latence pratiquement significative dans l'étape d'échange [4], bien que le coût de construction du ClientHello mérite une attention séparée.

Le temps de prise de contact n'est pas le seul endroit où le surcoût post-quantique peut apparaître. Une étude soutient que les études jusqu'à présent se sont concentrées sur le surcoût des algorithmes résistants aux quantiques sur le temps jusqu'au premier octet de TLS, c'est-à-dire le temps de prise de contact [9], et entreprend de combler une lacune : elle quantifie l'impact de ML-KEM et ML-DSA sur les connexions TLS 1.3 typiques qui transfèrent quelques centaines de Ko du serveur au client, étudiant le ralentissement du temps jusqu'au dernier octet [9]. Sa conclusion est que sous des conditions réseau stables, l'impact de ML-KEM et ML-DSA sur le temps jusqu'au dernier octet de TLS 1.3 est inférieur à l'impact sur le temps jusqu'au premier octet, et cet impact diminue à mesure que les données transférées augmentent [9]. Pour un développeur, cela signifie que les chiffres de latence de prise de contact discutés ci-dessus sont les plus pertinents pour les connexions de courte durée ou dominées par la prise de contact ; pour les transferts de charge utile plus importants, les mêmes algorithmes importent proportionnellement moins pour le temps total de connexion.

Le paysage de benchmarking plus large inclut également des travaux plus larges en portée mais non centrés sur OpenSSL spécifiquement. Une évaluation empirique multiplateforme couvre CRYSTALS-Kyber, NTRU, BIKE, CRYSTALS-Dilithium et Falcon, mesurant la latence de calcul, l'utilisation de la mémoire, les tailles de clés et le surcoût protocolaire à travers les Niveaux de sécurité 1, 3 et 5 du NIST dans trois environnements matériels distincts et diverses conditions réseau [12]. Une autre étude examine CRYSTALS-Kyber, HQC et BIKE spécifiquement à l'intérieur de la prise de contact TLS 1.3, avec une évaluation expérimentale complète de la latence de la prise de contact sous perte de paquets émulée [8]. Aucune de ces deux études n'est rapportée ici avec des chiffres ancrés sur OpenSSL 3.4+ ou sur les configurations nommées X25519Kyber768 ou X25519MLKEM512, donc elles doivent être lues comme un contexte pour le paysage KEM plutôt que comme des réponses directes à la question de cette note.

Du côté de l'authentification, qui interagit avec le coût de la prise de contact bien qu'il s'agisse d'un mécanisme séparé, Dilithium 2 et Falcon 512 surpassent RSA 4096 en durée de temps de prise de contact TLS [13]. Un développeur assemblant une configuration TLS 1.3 entièrement post-quantique dans OpenSSL doit choisir à la fois un KEM et un algorithme de signature, et cette conclusion est la pertinente pour le côté signature, indépendamment du KEM choisi.

Toute conclusion sur la latence ou la taille n'est utile que si elle correspond à ce qui est déployable et à ce qui est réellement déployé. L'étude de mesure de 2026 visait à identifier les primitives cryptographiques vulnérables aux quantiques, détecter la présence d'algorithmes post-quantiques ou hybrides, et analyser le déploiement réel de TLS à travers différents secteurs [14]. Ses chiffres principaux, déjà notés ci-dessus, sont que 49.3% des domaines prennent en charge l'échange de clés hybride post-quantique tel que MLKEM768 avec X25519, et 50.7% des domaines utilisent encore uniquement l'échange de clés classique [14]. Cette division signifie qu'un développeur visant une large compatibilité doit encore prendre en charge la négociation classique seule comme solution de repli pour environ la moitié des domaines observés, au moins au moment de cette mesure.

Plus préoccupant pour quiconque raisonnant sur la sécurité à long terme plutôt que seulement la latence : 0% d'adoption de certificats hybrides post-quantiques a été observée, laissant la couche d'authentification vulnérable aux attaques activées par les quantiques telles que la falsification de certificats [14]. Cela signifie que même là où un échange de clés hybride est déployé, la chaîne de certificats authentifiant cet échange n'est pas encore migrée nulle part dans l'ensemble mesuré. De plus, 15.70% des domaines, en particulier dans des secteurs critiques comme la banque et le gouvernement, reposent encore sur TLS 1.2 [14], une version de protocole qui précède entièrement les mécanismes PQC hybrides discutés tout au long de cette note.

Ces chiffres ne mesurent pas directement les configurations OpenSSL, et ils ne disent rien sur la latence ou la taille du code. Mais ils fixent le plafond pratique expliquant pourquoi la question de latence est posée en premier lieu : l'échange de clés hybride est à peu près à moitié déployé, l'authentification hybride n'est pas du tout déployée, et une fraction significative de l'écosystème n'a pas dépassé TLS 1.2. Un développeur optimisant pour la configuration KEM hybride la plus rapide doit garder à l'esprit que l'avantage de latence de la config ne comptera que pour environ la moitié des connexions qui peuvent actuellement la négocier, et que la couche certificat reste non traitée par la même migration.

La limite la plus importante a déjà été énoncée près du début : aucune affirmation dans cet ensemble ne mesure la taille du code pour aucune configuration KEM OpenSSL, donc la moitié taille du code de la question de recherche reste sans réponse par ces preuves [1]. Ce n'est pas une lacune mineure ; c'est l'une des deux quantités sur lesquelles la question porte, et un développeur ayant besoin d'un chiffre de taille de code doit se tourner vers des sources extérieures à cette note.

Deuxièmement, la conclusion de l'étude ARM64 selon laquelle ML-KEM-512 a montré les meilleures performances en raison de sa petite taille de paquet [1] est rapportée d'une seule étude sur une plateforme matérielle, ARM64, avec 100 itérations par configuration à travers cinq scénarios réseau [1]. C'est la seule affirmation de cet ensemble qui classe directement les configurations KEM les unes par rapport aux autres par performance mesurée ; elle n'a pas été vérifiée ici par une réplication indépendante sur une plateforme différente ou une version d'OpenSSL différente.

Troisièmement, la conclusion de l'étude par couches selon laquelle l'échange de la prise de contact est effectivement neutre algorithmiquement [4] et la conclusion de l'étude ARM64 d'un écart de 180 ms contre 281 ms sous 5% de perte de paquets [1] ont été produites par des groupes de recherche différents, probablement sous des conditions exactes différentes, et cette note n'a pas reçu une affirmation qui concilie leurs métriques en une seule échelle comparable. Un développeur devrait les traiter comme des preuves complémentaires à différents niveaux de granularité, taille d'effet de l'étape d'échange contre temps brut à l'horloge murale sous stress, plutôt que comme un seul nombre unifié.

Quatrièmement, plusieurs des études de benchmarking plus larges, couvrant Kyber, HQC, BIKE, NTRU, Dilithium et Falcon [8] [12] [13], ne sont pas rapportées ici avec des chiffres ancrés sur les noms de configuration exacts dans la question de recherche, X25519Kyber768 ou X25519MLKEM512, ou sur OpenSSL 3.4+ spécifiquement. Leur pertinence est contextuelle, pas une réponse directe. Enfin, les chiffres de déploiement [14] décrivent l'adoption à l'échelle d'Internet au moment de cette étude et peuvent ne pas refléter l'adoption actuelle ; ils ne mesurent pas non plus la performance, seulement la présence ou l'absence de support.

1. Mettre en place OpenSSL 3.x intégré avec liboqs comme pile de base, correspondant à l'environnement dans lequel les chiffres de latence de référence ont été produits [1] ; c'est une condition préalable pour reproduire ou étendre ces chiffres plutôt que de les deviner.
2. Énumérer les configurations KEM à tester : au minimum, X25519 simple comme base de référence classique, une configuration ML-KEM pure, et la configuration hybride X25519+ML-KEM-768, puisque cet hybride était l'une des configurations directement évaluées dans les expériences source [1].
3. Instrumenter la prise de contact pour enregistrer le temps d'établissement 1-RTT séparément du temps de redémarrage de session (reprise), car les temps de redémarrage de session ont constamment réduit la latence de la prise de contact pour tous les algorithmes dans l'étude de référence [1], et mélanger les prises de contact fraîches et reprises dans une seule mesure brouillera la comparaison.
4. Construire cinq bancs de test de conditions réseau correspondant à la conception de référence : boucle locale, LAN à 10 ms RTT, WAN à 50 ms RTT, perte de paquets 1%, et perte de paquets 5% [1]. Confirmez que votre banc produit exactement cinq conditions distinctes pour être une reproduction fidèle.
5. Exécuter 100 itérations par configuration et par condition réseau, correspondant au protocole de référence [1], et enregistrer la distribution complète, pas seulement la moyenne, afin que les valeurs aberrantes sous perte de paquets soient visibles.
6. Comparer la performance en état de base de chaque configuration KEM avec la fourchette de référence pour les prises de contact 1-RTT en état de base ML-KEM [1] comme vérification de cohérence que le banc de test se comporte de manière cohérente avec les chiffres publiés avant de tirer de nouvelles conclusions.
7. Sous la condition de perte de paquets de 5% spécifiquement, vérifier si les configurations de la famille ML-KEM restent plus proches des chiffres de référence rapportés pour ML-KEM par rapport à X25519 sous cette condition [1] ; une configuration performant bien en dehors des deux chiffres signale une différence de banc ou d'environnement qui nécessite une investigation avant de comparer les configurations entre elles.
8. Séparément, instrumenter et mesurer le temps de construction du ClientHello seul, distinct du temps d'échange complet de la prise de contact, puisque le coût sensible à l'algorithme se situe dans la construction du ClientHello plutôt que dans l'étape d'échange elle-même [4]. Sauter cette séparation est un point de défaillance courant : mesurer uniquement le temps total de prise de contact masquera où réside réellement un éventuel coût dépendant de l'algorithme.
9. Si la taille du code importe pour la cible de déploiement, la traiter comme une tâche de mesure séparée et non traitée : compiler la construction OpenSSL/liboqs pour chaque configuration et enregistrer la taille du binaire ou de la bibliothèque directement. Aucune affirmation dans cette note ne fournit une base de référence ou une fourchette attendue pour cela, donc tout chiffre produit ici est un nouveau travail, pas une reproduction de résultats antérieurs.
10. Si le déploiement implique des transferts de charge utile plus importants plutôt que des connexions courtes dominées par la prise de contact, mesurer également le temps jusqu'au dernier octet pour un transfert représentatif de quelques centaines de Ko, car une étude a trouvé que l'impact post-quantique sur le temps jusqu'au dernier octet est inférieur à celui sur le temps jusqu'au premier octet et diminue à mesure que les données transférées augmentent [9] ; cela change quelle configuration importe le plus selon la taille typique de connexion dans le déploiement cible.
11. Rapporter les résultats avec la condition réseau explicite, le nombre d'itérations et la plateforme matérielle attachés à chaque nombre, suivant le motif des études de référence [1] [12], afin que tout lecteur puisse juger si un résultat se généralise au-delà de l'environnement testé.

for config in [X25519, ML-KEM-512, ML-KEM-768, X25519+ML-KEM-768]:
  for scenario in [loopback, LAN_10ms, WAN_50ms, loss_1pct, loss_5pct]:
    for i in 1..100:
      measure(ClientHello_construction_time)
      measure(full_handshake_time)
      measure(session_restart_time)
    record distribution, not just mean
compare each config's numbers against reference ranges [1]
if code_size_required: compile and measure binary size separately (no reference baseline exists)