Un examen approfondi des performances de ML-KEM

Cet article de blog fait partie d'une série où j'aborde la migration post-quantique sous l'angle technique. Notre objectif est de comprendre les problèmes à résoudre, ainsi que comment et pourquoi certaines décisions sont prises. Au fond, il s'agit de comprendre. Les deux premiers articles ont couvert les défis liés à l'augmentation de la taille des signatures et aux nouvelles méthodes d'établissement de clés. Dans le troisième, nous avons examiné les couches réseau et le protocole TLS pour comprendre quels aspects influencent les performances et comment ceux-ci seront affectés par la migration.

Dans ce quatrième article, nous examinons les nouvelles options d'établissement de clés impliquant ML-KEM pour comprendre comment elles se comportent en pratique. C'est la partie de la migration post-quantique déjà mise en œuvre, du moins dans le protocole TLS. Les décisions ont été prises, voyons donc comment elles ont affecté les performances sur le réseau.

Avant d'entamer la migration post-quantique, TLS 1.3 proposait deux options pour l'établissement de clés, toutes deux basées sur l'algorithme Diffie-Hellman ; l'une classique, l'autre en courbes elliptiques. On les appelle habituellement DHE et ECHDE. (Le dernier « E » de l'abréviation signifie ephemeral, éphémère. C'est un avantage, car cela garantit la forward secrecy.) ECHDE était et reste l'option dominante, grâce à de meilleures propriétés de sécurité pour des clés plus petites, de meilleures performances, et un besoin de stockage réduit sur le réseau.

Avec la migration post-quantique, TLS est passé à l'établissement de clés hybride, qui combine ECDHE avec le standard ML-KEM adopté par le NIST. Comme il s'agit d'un hybride, chaque handshake TLS transporte des informations sur deux algorithmes ; on fait littéralement tout en double. Quel a été l'impact sur le protocole ?

Pour le découvrir, j'ai ressorti un vieil outil à moi (un fork d'un travail antérieur de Vincent Bernat) que j'avais déjà utilisé pour ce type de mesure. Je l'ai porté sur OpenSSL 3.5.5, livré avec Ubuntu 26.04 LTS. Cette version d'OpenSSL [ou à peu près] est celle qui équipe actuellement les dernières versions LTS des systèmes d'exploitation.

Mon outil est conçu pour mesurer les besoins en CPU et en transport réseau de différentes suites cryptographiques, algorithmes d'établissement de clés et protocoles. Pour cette étude, j'ai choisi de tester quatre options :

• Clé ECDSA-256 associée à ECDHE-X25519 – la référence, une option moderne et rapide.
• Clé RSA-2048 associée à ECDHE-X25519 – légèrement plus lente à cause de RSA.
• Clé ECDSA-256 associée à X25519MLKEM768 – la nouvelle option hybride PQC.
• Clé ECDSA-256 associée à ML-KEM-1024 – la nouvelle option PQC pure.

Nous ne pouvons tester que TLS 1.3, car TLS 1.2 et les versions antérieures ne seront pas adaptées à la cryptographie post-quantique.

La mesure est réalisée sur le même ordinateur, en exécutant un client complet et un serveur complet, dans le même processus mais sur des threads distincts. Nous mesurons la consommation CPU et surveillons la taille de chaque handshake. Chaque exécution a comporté 2 000 handshakes et a été répétée 3 à 5 fois pour stabiliser les valeurs. Notez que les mesures CPU correspondent au temps CPU, ce qui suffit pour comparer un établissement de clés à un autre, mais ces valeurs ne sont pas comparables à des mesures réalisées ailleurs.

Regardons d'abord l'utilisation du CPU pendant l'établissement de clés.

On comprend immédiatement pourquoi ECDSA est actuellement l'algorithme de clé privilégié par rapport à RSA. Avec ce dernier, le serveur doit effectuer 2,5 fois plus de travail à chaque handshake. Il existe aussi une asymétrie notable dans le temps CPU consommé côté client et côté serveur : les serveurs effectuent 3 fois plus de travail au total.

J'ai inclus RSA à titre de comparaison mais, pour nos besoins, nous pouvons exclure cette mesure et nous concentrer sur les trois autres, qui utilisent toutes ECDSA. Le verdict ? Il n'y a pas de différence significative de temps CPU, quel que soit l'établissement de clés utilisé. C'est parce que ML-KEM est très rapide. Bien qu'il existe des hausses relatives non négligeables, les écarts en valeur absolue restent minimes.

Examinons maintenant la quantité de données échangées entre client et serveur.

On observe ici des différences importantes. En comparant les deux mesures ML-KEM à la référence X25519, on constate que X25519MLKEM768 ajoute 1 176 octets au handshake côté client et 1 088 octets côté serveur. Des deux, la hausse côté serveur (2x) est la plus significative, car elle prend de la place dans la fenêtre de congestion initiale, qui constitue le goulot d'étranglement auquel nous serons confrontés en pratique.

ML-KEM-1024, un algorithme plus robuste, occupe encore plus de place. Le côté serveur du handshake augmente de 1 537 octets, soit environ 2,6 fois plus.

Comme vous vous en souvenez peut-être de mes précédents articles, nous utilisons ML-KEM-1024 pour la mesure ML-KEM pure car c'est le minimum accepté par la NSA dans le cadre de leur exigence Commercial National Security Algorithm (CNSA) 2.0.

Ces mesures ne racontent pas toute l'histoire, car le client et le serveur tournent tous deux sur la même machine, avec une latence réseau infime. Même à ce niveau, on constate que ML-KEM pur est légèrement moins performant que les autres méthodes ; il nécessite à peu près le même CPU, mais davantage d'octets dans le handshake.

En pratique, il faut tenir compte du fait que les clients TLS ne peuvent envoyer qu'un petit nombre de partages de clés dans leur ClientHello initial. Aujourd'hui, X25519 et X25519MLKEM768 sont envoyés, mais pas ML-KEM-1024. Cela signifie que tout serveur souhaitant cette dernière option doit répondre par une demande de nouvelle tentative à chaque connexion TLS complète, ce qui ajoute un aller-retour supplémentaire au handshake.

Ajouter ML-KEM-1024 comme troisième partage de clés par défaut n'a guère de sens, la plupart du monde ne l'utilisant pas. Pour l'instant, les serveurs ayant besoin d'une option PQC pure devront accepter cette pénalité de performance.

Cela ne devrait pas poser de problème sur les réseaux locaux, où les allers-retours se mesurent en quelques millisecondes, mais la pénalité de performance sera clairement perceptible sur l'internet public. Si nous savions quels établissements de clés sont pris en charge par un serveur donné, nous pourrions n'envoyer qu'un seul partage de clés, mais nous ne disposons pas actuellement de la technologie pour diffuser cette information. Un projet de RFC en cours (« TLS Key Share Prediction ») explore l'utilisation du DNS à cette fin, via les enregistrements SVCB et HTTPS.