Pourquoi les signatures post-quantiques dépassent les limites du handshake TLS

En ce qui concerne la transition vers la cryptographie post-quantique, certains aspects sont plus simples que d'autres. La transition de l'établissement de clé vers une approche résistante aux attaques quantiques a demandé des efforts, mais nous sommes arrivés à une solution (une approche hybride, combinant les courbes elliptiques avec ML-KEM) sans trop de difficulté. Pour les certificats et l'authentification, cela va demander bien plus de travail, et tout se joue sur les différences de tailles de signature entre les algorithmes que l'on utilise aujourd'hui (traditionnels) et ceux que l'on souhaite utiliser demain (post-quantiques).

Quand nous concevons un protocole (cryptographique ou autre), nous prenons en compte de nombreux facteurs, évaluons les différentes options et leurs avantages ou inconvénients, puis faisons nos choix afin de respecter les contraintes auxquelles nous sommes soumis. La sécurité n'est généralement pas négociable (même si elle s'inscrit souvent sur un spectre), mais les performances sont un facteur clé. Historiquement, nous apprécions la sécurité, mais nous adorons la cryptographie rapide.

Certaines choses créent de la dépendance, et c'est exactement ce qui s'est produit avec la cryptographie à courbes elliptiques. Elle semblait être un outil parfait, à la fois sécurisé et performant, avec des opérations rapides et de petites tailles de signatures. Au fil des ans, de plus en plus de protocoles sont passés à cette famille d'algorithmes cryptographiques, jusqu'à ce qu'elle soit omniprésente. Les besoins étaient faciles à satisfaire en ajoutant une nouvelle signature, jusqu'à ce que tout soit brutalement remis en cause par l'arrivée des ordinateurs quantiques. (Si vous souhaitez un rappel, notre Guide de la cryptographie post-quantique se lit facilement et reste accessible.)

La transition vers la cryptographie post-quantique, imposée par la menace d'un ordinateur quantique d'importance cryptographique (CRQC), nous rappelle très bien que, dans le monde numérique, il n'existe pas de sécurité inhérente. Tout n'est qu'une question de jeux de stratégies. On joue avec les mathématiques et on en tire des propriétés intéressantes qu'on assemble de façon utile. La notion de sécurité est éphémère, car l'état de l'art progresse sans cesse. Vous avez peut-être déjà entendu que les attaques ne font que s'améliorer.

Nos ordinateurs classiques sont incapables de casser les mathématiques de RSA et d'ECDSA, mais, il se trouve que les ordinateurs quantiques le peuvent. Pour nous en protéger, il faut recourir à de nouveaux stratagèmes, basés sur des mathématiques différentes. Nous élaborons de nouveaux algorithmes. Le seul souci, c'est que les propriétés de ces nouveaux algorithmes diffèrent. Dans ce cas précis, les performances restent comparables, mais les clés et les signatures prennent beaucoup plus de place.

Dans le tableau ci-dessous, nous comparons les aspects clés de ML-DSA à ceux de la cryptographie dite traditionnelle. Nous présentons les différentes valeurs pour les algorithmes et forces couramment utilisés dans les certificats feuilles et intermédiaires (qui utilisent une cryptographie plus robuste). Nous nous concentrons sur ML-DSA, car c'est notre principal choix à ce jour. Si vous voulez voir à quoi ressemblent les autres algorithmes, parcourez le PQC Signature Zoo.

Comme vous pouvez le constater, la variante d'entrée de gamme ML-DSA utilise des signatures 10 fois plus grosses que RSA et 34 fois plus que ECDSA. Cette explosion de la taille de la cryptographie à clé publique bouleverse nos hypothèses d'origine, à tel point que certains systèmes pourraient tout simplement cesser de fonctionner correctement.

Au passage, si vous constatez de légères différences dans les tailles indiquées pour les clés publiques et les signatures d'un article à l'autre, c'est probablement parce que certains se basent sur la taille des primitives brutes, tandis que d'autres, comme ici, tiennent compte de l'encodage lors du transport sur le réseau.

Au fond, un certificat X.509 est un véhicule destiné à emballer et transporter une clé publique, qui est signée par l'autorité compétente. À l'origine, les certificats n'utilisaient que des clés RSA. Avec la désormais classique taille de 2 048 bits, une clé RSA occupe 272 octets et sa signature 256. Avec ECDSA, la clé publique prend 65 octets (sans compression) et la signature 72. Avec les métadonnées indispensables de chaque certificat, la taille d'un certificat feuille typique atteint 1 à 2 Ko.

Un certificat seul ne suffit pas pour accéder à un serveur en toute sécurité. En pratique, on s'appuie sur des chaînes de certificats comportant au minimum 2 certificats transmis sur le réseau. (Une chaîne complète implique 3 certificats, si l'on compte la racine, mais ce dernier ne doit normalement pas être transmis.)

Ce certificat intermédiaire supplémentaire double les exigences en termes de taille. Les intermédiaires et racines utilisent généralement une cryptographie plus robuste, ce qui les rend encore plus volumineux.

À cela s'ajoute qu'il faut au moins une signature pour authentifier la poignée de main cryptographique en direct. Dans le cas du handshake TLS, nous avons donc, au minimum, 3 signatures et 2 clés publiques.

Aux premiers temps du SSL, les processeurs étaient lents et la cryptographie extrêmement exigeante. Les opérations cryptographiques étaient alors le point de blocage principal. (Et en prime, les pages web étaient beaucoup plus petites qu'aujourd'hui !) Désormais, le goulot d'étranglement tient à un phénomène dont vous n'avez peut-être jamais entendu parler : la fenêtre de congestion initiale de TCP.

Pour faire simple, la fenêtre de congestion initiale représente la quantité maximale de données qu'un serveur peut transmettre dès l'ouverture d'une connexion TCP, sans devoir attendre une autorisation supplémentaire du réseau. Cette fenêtre était autrefois très réduite, mais elle s'élève désormais à 14,5 Ko environ. QUIC, remplaçant moderne de TCP (fonctionnant sur UDP), impose une limite d'environ 4 500 octets seulement, pour une toute autre raison (la défense anti-amplification, visant à limiter les attaques DoS d'amplification faciles à réaliser sur UDP).

En résumé, si le serveur ne parvient pas à faire tenir tous ses certificats et éléments cryptographiques protocolaires dans ces 14,5 Ko, il devra attendre le feu vert du client au moment le plus sensible de l'échange, c'est-à-dire tout au début. Sur un bon réseau, la pénalité de performance se compte en dizaines de millisecondes. Sur un réseau mobile, on peut atteindre les centaines.

Si votre protocole fonctionne sur UDP (à nouveau QUIC), des paquets de grande taille impliqueront alors une fragmentation, souvent bloquée par des équipements intermédiaires. Et si le réseau souffre d'une grande perte de paquets, la performance sera encore dégradée.

Les certificats X.509 classiques, décrits plus tôt, ne sont plus la norme sur le web d'aujourd'hui. Peut-être sur un réseau privé, mais dans le Web PKI, on exige la version enrichie de X.509, complétée par la Certificate Transparency (CT). L'écosystème CT multiplie les garanties sécuritaires en imposant que tous les certificats publics soient enregistrés dans des registres publics. La publication est vérifiée, actuellement par au moins 2 opérateurs. Chacun fournit une signature, intégrée au certificat X.509 dans l'extension Signed Certificate Timestamp (SCT).

Avec la CT, on monte ainsi à 5 signatures et 2 clés publiques dans une poignée de main TLS typique.

Sans entrer dans le détail des calculs (ce sera peut-être le sujet d'un autre article), voici les ordres de grandeur que j'ai observés pour les chaînes couramment utilisées aujourd'hui :

• Chaîne de certificats ECDSA : 586 octets
• Chaîne de certificats RSA : 1 712 octets
• Chaîne de certificats ML-DSA : 14 724, 18 640 ou 18 565 octets

Les résultats ML-DSA méritent explication. On atteint la plus petite taille (14 724) si toute la chaîne est en ML-DSA-44, ce qui va à l'encontre des bonnes pratiques. Le second chiffre (18 640) concerne l'utilisation d'une cryptographie plus forte sur les intermédiaires et racines, car ces clés doivent rester sécurisées plus longtemps. Le troisième chiffre s'applique à l'usage de CNSA 2.0 (la suite Commercial National Security Algorithm de la NSA), qui exige uniquement ML-DSA-87.

Clairement, même dans le meilleur des cas avec une chaîne ML-DSA, la cryptographie publique explose d'emblée le seuil des 14 Ko de la fenêtre de congestion initiale, et personne ne souhaite cela. Cette hausse devrait avoir un petit impact, mais non négligeable, sur notre usage quotidien. Les appareils contraints (type IoT) auront peut-être même du mal à mettre en œuvre la cryptographie post-quantique tout court.

Ce calcul ne concerne que l'essentiel, mais il existe nombre de situations où le handshake TLS prendra encore plus de place. Par exemple :

• Il faut parfois ajouter un certificat intermédiaire supplémentaire, par exemple lors d'une transition hiérarchique, pour conserver la compatibilité avec les magasins de racines plus anciens.
• La situation empire si l'on opte pour l'authentification hybride, c'est-à-dire le mélange de cryptographie traditionnelle et post-quantique dans un même certificat. On peut faire ce choix si l'on ne fait pas entièrement confiance aux nouveaux algorithmes post-quantiques et qu'on préfère la ceinture et les bretelles.
• Ce sera à nouveau un peu pire si vous souhaitez prendre en charge la révocation via OCSP, une fonctionnalité aujourd'hui rarement utilisée sur l'internet public.

On l'a vu, une transition naïve vers les algorithmes post-quantiques implique sans doute une perte de performance significative. Dans le prochain article, j'explorerai les éléments concrets qui pourraient corroborer ces craintes.