Effet des algorithmes post-quantiques sur les performances réseau

Dans les deux premiers articles de cette série, j'ai couvert deux efforts clés de la cryptographie post-quantique : l'un pour corriger l'établissement de clés, l'autre pour corriger l'authentification. Bien qu'il s'agisse de deux problèmes différents, ils ont un point commun : les deux changements affecteront les performances des protocoles réseau chiffrés.

Les effets des changements d'établissement de clés sont beaucoup évoqués, mais Google a observé une légère augmentation de la latence du handshake. Cela ne semble pas énorme, mais ça compte à grande échelle. Il existe une inquiétude bien plus grande concernant la taille des signatures post-quantiques, où les effets pourraient être bien pires, selon l'approche retenue.

Pour comprendre pourquoi ces choses se produisent, il faut d'abord comprendre les principes fondamentaux du chiffrement, puis la manière dont TLS les utilise pour assurer la sécurité. Dans cet article, je détaille le handshake TLS, en mettant en lumière les parties liées à l'établissement de clés et à l'authentification, ainsi que l'effet des changements post-quantiques sur cette partie essentielle de la communication chiffrée.

À un niveau général, quand on parle de chiffrement, on cherche surtout ce qu'il peut apporter, généralement décrit selon trois aspects : la confidentialité, l'authentification et l'intégrité. Pour obtenir ces propriétés, on combine des primitives cryptographiques afin de concevoir des protocoles. Dans tout protocole cryptographique, l'essentiel de la complexité se trouve dans le handshake, qui accomplit globalement ce qui suit :

• Se mettre d'accord sur des paramètres de chiffrement communs
• S'authentifier, idéalement des deux côtés mais le plus souvent seulement côté serveur
• Se mettre d'accord sur les clés de chiffrement (établissement de clés)
• Valider l'intégrité du handshake pour s'assurer qu'il n'y a pas eu d'altération

Il se passe beaucoup de choses là-dedans. Les protocoles répandus doivent aussi résoudre l'interopérabilité, c'est-à-dire l'art de faire dialoguer des centaines d'outils et de produits fabriqués par des constructeurs différents, malgré des implémentations souvent imparfaites, anciennes et parfois obsolètes.

La partie chiffrement à proprement parler est presque ennuyeuse comparée au handshake, surtout aujourd'hui où le chiffrement authentifié est la norme. Il suffit d'indiquer l'algorithme de chiffrement souhaité et la clé à utiliser, de fournir des données en entrée, puis d'obtenir des données en sortie. Pour empêcher des attaques comme le rejeu, la réorganisation ou la suppression de données, tous les paquets chiffrés forment une chaîne immuable et partagent un contrôle d'intégrité commun et continu.

Nous avons déjà établi la complexité des protocoles cryptographiques. Dans TLS, un handshake se compose de plusieurs échanges (flights). Au sein de chaque échange, plusieurs messages du protocole sont envoyés d'un côté à l'autre, quasiment en même temps. Voici un schéma simple (il existe un schéma détaillé plus complet dans la RFC, si cela vous intéresse) :

1. Le client démarre le handshake en envoyant un message ClientHello.
2. Le serveur accepte la connexion, bascule vers le chiffrement, envoie son certificat, prouve qu'il détient la clé privée correspondante, puis termine le handshake.
3. Le client valide les données du serveur et termine le handshake de son côté. Il procède ensuite à l'envoi des données applicatives (par exemple, HTTP).
4. Le serveur termine le handshake de son côté, puis répond aux données applicatives.

Quand on observe le handshake du point de vue réseau, on voit que chaque échange se compose d'un ou plusieurs paquets réseau, selon la quantité de données à envoyer. Comme il faut du temps aux paquets pour atteindre l'autre extrémité, et à la réponse pour revenir, il y a aussi une part d'attente entre les échanges. Un handshake TLS complet nécessite deux allers-retours entre client et serveur. Nous y reviendrons plus loin.

Chaque handshake implique les éléments suivants :

• Des opérations cryptographiques sur le CPU
• La construction des messages du protocole
• L'envoi d'octets sur le réseau
• L'attente d'une réponse de l'autre côté
• Le traitement des paquets reçus

Pour en savoir plus, consultez la RFC 9846, récemment mise à jour pour TLS 1.3. Ensuite, lancez Wireshark et observez les vrais handshakes réalisés par les navigateurs et autres outils.

Le prix de la cryptographie se paie en traitement CPU accru et en latence réseau. Pour la première, il suffit d'acheter plus de CPU. Pour la seconde, la latence réseau ralentit nos sites web, ce qui se traduit par moins de revenus.

Regardons ces deux aspects plus en détail :

• CPU : Aux débuts de la cryptographie, les CPU étaient bien plus lents qu'aujourd'hui et représentaient un goulot d'étranglement important. À l'époque, il était courant de ne chiffrer qu'une partie du trafic. Heureusement, les choses vont bien mieux aujourd'hui, et on peut tout chiffrer. La cryptographie a un coût mesurable, mais il reste faible comparé aux bénéfices.
• Latence : Le vrai coût de la cryptographie réside dans les allers-retours supplémentaires qu'elle entraîne. Pour réaliser un handshake TCP, il faut un aller-retour. On envoie une requête, qui traverse le réseau, puis on attend que la réponse revienne. Pour réaliser un handshake TLS par-dessus une connexion TCP déjà ouverte, il faut deux allers-retours supplémentaires. Ainsi, pour démarrer une nouvelle connexion entre Londres et New York, on ne peut pas faire l'économie de 3x90=270ms d'attente pour que les paquets fassent l'aller-retour. QUIC, qui s'appuie sur UDP, peut ouvrir une connexion plus rapidement, en seulement 180ms.

Concernant la cryptographie post-quantique, qui, dans le contexte de TLS, désigne aujourd'hui ML-KEM (pour l'établissement de clés) et ML-DSA (pour l'authentification), les différences en matière de besoins CPU ne sont pas significativement différentes.

L'histoire est complètement différente pour la latence réseau, qui a le potentiel d'affecter négativement les performances en imposant des conditions qui augmentent le nombre d'allers-retours nécessaires pendant la phase initiale du handshake. Cela peut se produire via l'un des deux mécanismes suivants :

• Hypothèses sur les partages de clés : Dans TLS 1.3, les clients doivent « deviner » quels partages de clés pourraient être pris en charge par un serveur. Historiquement, tous les serveurs TLS 1.3 prenaient en charge X25519, c'est donc ce que tout le monde envoyait. Aujourd'hui, les clients modernes envoient X25519 ainsi que X25519MLKEM768, et cela fonctionne la plupart du temps. Quand ce n'est pas le cas, le serveur doit demander une nouvelle tentative du ClientHello, via un message HelloRetryRequest. Ce message contient les informations sur les méthodes d'établissement de clés prises en charge par le serveur. Si le serveur prend en charge un algorithme correspondant, il peut réessayer, mais ce processus ajoute un aller-retour supplémentaire.
• Démarrage lent : Au début d'une nouvelle connexion, les conditions réseau sont inconnues, et les protocoles démarrent généralement lentement, en augmentant la vitesse à mesure que davantage de paquets sont échangés. Cette approche s'appelle généralement le Slow Start en TCP, et il en existe des équivalents dans d'autres protocoles (par exemple, QUIC). La quantité de données pouvant être envoyée initialement s'appelle la fenêtre de congestion initiale. La valeur par défaut pour les serveurs aujourd'hui est d'environ 14,5 Ko, bien que les CDN puissent autoriser des valeurs plus élevées, par exemple 30 à 45 Ko. En résumé, une fois que vous avez envoyé toutes les données autorisées, vous devez attendre une réponse, ce qui ajoute un aller-retour supplémentaire.

C'est donc la fenêtre de congestion initiale qui constitue le nouveau goulot d'étranglement. Si vous vous souvenez de mon précédent article où j'évoquais la taille des signatures post-quantiques, une transition directe des signatures ECDSA vers ML-DSA dans les certificats et les messages du protocole pourrait ajouter entre 14 et 18 Ko au handshake TLS, ce qui ferait complètement exploser la fenêtre de congestion initiale par défaut pour la plupart des serveurs.

Bien qu'il soit toujours possible d'augmenter la taille de la fenêtre de congestion initiale (à condition que nos réseaux puissent le supporter), il faut aussi tenir compte du fait que négocier TLS n'est pas une fin en soi : il faut ensuite superposer un protocole applicatif. En pratique, cela signifie qu'on souhaite, idéalement, livrer la page d'accueil entière du site en une seule fois, afin que le navigateur puisse commencer à la traiter.

En plus d'entraîner des coûts et des ralentissements, des changements aussi importants provoquent souvent des ruptures. C'est en tout cas un problème dont il faut s'occuper en matière de performance réseau.

Comme nous l'avons vu, dans TLS le handshake démarre par un ClientHello. Dans ce message, le client soumet sa requête au serveur et fournit les paramètres initiaux. Il y a longtemps, ce message était plutôt petit, moins de 256 octets même. Au fil des années, à mesure que la complexité de TLS augmentait, la taille du ClientHello a grandi, mais est restée dans la limite d'un seul paquet réseau. En conséquence, une grande partie des logiciels existants ont été écrits en partant du principe que le ClientHello entier arriverait toujours en un seul paquet.

Cette hypothèse s'est effondrée récemment quand nous avons mis à niveau l'établissement de clés dans TLS pour intégrer ML-KEM-768, qui exige 1 216 octets supplémentaires. En vérifiant un ClientHello réel à l'instant, je l'ai observé à 2 117 octets dans la dernière version de Chrome. C'est bien au-delà de ce qui peut être envoyé via un seul paquet (environ 1 440 octets de données utiles).

En conséquence, ces nouveaux ClientHello volumineux traversent le réseau en deux segments TCP, et certains logiciels et appareils ne savent pas gérer cela, pour diverses raisons. Ce sont généralement les tristement célèbres middleboxes, des dispositifs conçus pour inspecter le trafic réseau.

TLS a une longue histoire de problèmes avec les middleboxes. Presque à chaque évolution nécessaire du protocole, les middleboxes se sont mises en travers du chemin. Cela a fini par donner naissance à GREASE, une méthode consistant à insérer des données factices aléatoires pour empêcher toute hypothèse sur ce qui peut ou non apparaître dans les paquets TLS.

Même en l'absence de problème avec des dispositifs intermédiaires, un ClientHello plus volumineux signifie plus de données et plus de paquets envoyés. Vos communications sont plus lentes, et le risque de perte de paquets augmente, ce qui peut entraîner des retransmissions. C'est ce qui a été signalé par Google comme une augmentation médiane de 4 % de la latence du handshake. Sur ordinateur, c'est encore pire sur mobile.