Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

Cette étude de laboratoire analyse l'impact des algorithmes de cryptographie post-quantique sur les performances des transactions HTTP sur TLS 1.3 à travers plusieurs couches, en comparant les échanges de clés traditionnels, hybrides et purement post-quantiques dans un scénario de charge simulée.

L'essentiel

Voici une explication simple et imagée de cette étude scientifique, conçue pour être comprise par tout le monde, sans jargon technique.

🛡️ Le Grand Défi : Préparer nos serrures pour l'ère des ordinateurs quantiques

Imaginez que la sécurité d'Internet repose sur des serrures très complexes (les algorithmes de cryptographie actuels). Aujourd'hui, ces serrures sont incassables. Mais les scientifiques prévoient l'arrivée d'un jour où des ordinateurs ultra-puissants (les ordinateurs quantiques) pourront forcer ces serrures en quelques secondes.

Pour se préparer, nous devons installer de nouvelles serrures, dites "post-quantiques", qui résisteront à ces futurs géants. Le problème ? Ces nouvelles serrures sont plus lourdes et plus complexes. La question de l'étude est simple : Est-ce que changer de serrure va ralentir notre navigation sur Internet ?

🏗️ L'expérience : Une course de relais en 5 étapes

Les chercheurs ont créé un laboratoire virtuel pour tester trois types de serrures sur un serveur web (comme un site e-commerce) :

1. Classique (l'actuelle, vulnérable aux futurs ordinateurs quantiques).
2. Hybride (un mélange de l'ancienne et de la nouvelle, pour la sécurité maximale).
3. Pure Post-Quantique (la nouvelle, toute seule).

Pour comprendre où se perd le temps, ils n'ont pas seulement mesuré le temps total. Ils ont découpé la transaction en 5 étapes d'une course de relais :

1. Le coup de sifflet (TCP Handshake) : Le client dit "Bonjour" au serveur.
2. La préparation (TCP vers TLS) : Le client sort ses outils et prépare sa nouvelle serrure.
3. L'échange des clés (TLS Handshake) : Ils échangent les codes secrets pour verrouiller la porte.
4. Le passage du guichet (TLS vers App) : La porte est ouverte, on demande le colis.
5. La livraison (Application) : Le colis (la page web) arrive.

🔍 Les découvertes surprenantes

Voici ce que les chercheurs ont observé en comparant les temps de chaque étape :

1. Le coup de sifflet reste identique 🏃‍♂️

L'étape 1 (le "Bonjour" initial) ne change absolument rien, que ce soit avec une vieille ou une nouvelle serrure. C'est comme si le temps de courir vers le stade restait le même, peu importe le type de chaussures que vous portez.

2. La préparation est le vrai goulot d'étranglement 🎒

C'est ici que tout se joue ! L'étape 2 (la préparation de la nouvelle serrure par le client) prend 6 fois plus de temps avec les nouvelles technologies.

• L'analogie : Imaginez que pour entrer dans un concert, avec l'ancienne méthode, vous sortiez juste votre billet de poche (rapide). Avec la nouvelle méthode, vous devez sortir un gros sac à dos, ouvrir un cadenas complexe, et vérifier un code à 10 chiffres avant même d'arriver à la porte. Cela prend du temps, mais c'est une fois pour toutes.

3. L'échange des clés est étonnamment rapide ⚡

C'est la grande surprise de l'étude ! Une fois la préparation faite, l'étape 3 (l'échange réel des clés) est aussi rapide, voire légèrement plus rapide, avec les nouvelles serrures qu'avec les anciennes.

• L'analogie : Une fois le sac à dos ouvert, le processus de vérification du billet est en fait très fluide. Les chercheurs pensaient que cette étape serait lente, mais elle est en réalité "neutre". La nouvelle technologie est si bien conçue qu'elle compense son propre poids.

4. La livraison ne change pas 📦

Une fois la porte ouverte, le temps pour recevoir la page web (l'étape 5) dépend uniquement de la taille du colis (la taille de la page web), pas de la serrure. Que le colis soit petit (4 Ko) ou gros (40 Ko), la nouvelle serrure ne le ralentit pas.

📉 Le verdict final : Est-ce grave ?

Non, pas vraiment.

Bien que la préparation prenne plus de temps (environ 1,5 milliseconde de plus), cela ne représente qu'une petite fraction du temps total de chargement d'une page web.

• L'analogie du voyage : Si votre trajet en voiture prend 20 minutes, et que vous devez passer 1 minute de plus à vérifier votre permis de conduire à l'entrée de l'autoroute, le trajet total ne passe pas de 20 à 30 minutes, mais de 20 à 21 minutes. C'est une augmentation de 15%, mais c'est imperceptible pour le conducteur.

De plus, plus le colis (la page web) est gros, plus cette petite perte de temps devient insignifiante. Si vous téléchargez un gros fichier, le temps perdu à la préparation devient négligeable par rapport au temps de téléchargement.

💻 L'impact sur les ordinateurs (CPU)

Il y a un petit bémol :

• Pour le serveur (le magasin) : L'impact est minime.
• Pour le client (votre téléphone ou PC) : Le processeur travaille environ deux fois plus pour préparer la nouvelle serrure.
  • Conséquence : Pour un ordinateur puissant, ce n'est rien. Mais pour un petit appareil (comme un capteur IoT ou un vieux téléphone), cela pourrait consommer plus de batterie.

🚀 Conclusion

Cette étude nous rassure : Passer à la sécurité post-quantique est faisable sans casser Internet.

Le ralentissement est réel, mais il est concentré au tout début de la connexion (la préparation) et est très faible par rapport au temps total. C'est comme changer de serrure dans une maison : cela prend quelques minutes de plus pour l'installer, mais une fois en place, la maison est aussi sûre, et peut-être même plus facile à ouvrir au quotidien, sans ralentir vos visites.

En résumé : On peut installer ces nouvelles serrures quantiques dès maintenant. Elles sont un peu plus lourdes à porter au début, mais elles ne ralentissent pas notre voyage vers le futur.

Résumé technique

Voici un résumé technique détaillé de l'article "Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange", rédigé en français.

1. Problématique et Contexte

L'avènement des ordinateurs quantiques menace la sécurité des infrastructures à clé publique actuelles (RSA, ECDH). En réponse, le NIST a finalisé en août 2024 les premières normes de cryptographie post-quantique (PQC), notamment ML-KEM (FIPS 203). Bien que la migration vers ces algorithmes soit urgente pour contrer les attaques "stocker maintenant, déchiffrer plus tard", il existe un manque de données empiriques quantifiant l'impact de performance de ces algorithmes dans des environnements réels.

La plupart des études précédentes se sont limitées à mesurer la latence globale du handshake TLS, sans décomposer les différentes couches du protocole. Cela rend difficile l'attribution précise des surcoûts (overhead) à des phases spécifiques (ex: génération de clés, échange de messages, traitement réseau). Cette étude vise à combler ce vide en analysant l'impact du PQC sur chaque couche de la transaction HTTP sur TLS 1.3.

2. Méthodologie et Configuration Expérimentale

Les auteurs ont conçu une architecture de laboratoire reproduisant un scénario de production réaliste pour évaluer les performances sous charge.

• Architecture :
  • Client : Générateur de trafic étatique haute performance (Keysight CyPerf) simulant des utilisateurs virtuels.
  • Serveur : Nginx 1.27.3 agissant comme proxy inverse, utilisant une version personnalisée d'OpenSSL 3.4.0 intégrée avec la bibliothèque liboqs (Open Quantum Safe) pour supporter les algorithmes PQC.
  • Backend : Un agent CyPerf simulant le serveur d'application, renvoyant des réponses HTTP de tailles variables.
• Charge de travail : Tests de charge soutenus à 100 transactions par seconde (TPS) sur une durée de 5 minutes, générant environ 30 000 requêtes par test (total d'environ 1 million de requêtes sur l'ensemble de l'étude).
• Configurations comparées :
  1. Classique : Échange de clés ECDH (x25519).
  2. Hybride : Combinaison ECDH + ML-KEM (x25519_MLKEM512, x25519_MLKEM768).
  3. PQC Pur : ML-KEM seul (MLKEM512, MLKEM1024).
• Variables : Taille de la réponse du backend (directe, 4 Ko, 40 Ko).
• Analyse des données : Utilisation d'outils de capture de paquets (pcap) et de logs de clés TLS (SSLKEYLOGFILE) pour décrypter le trafic et décomposer la latence en couches distinctes :
  1. Handshake TCP (SYN → SYN-ACK).
  2. Délai TCP vers TLS (SYN-ACK → ClientHello).
  3. Handshake TLS (ClientHello → Finished).
  4. Délai TLS vers Application (Finished → HTTP GET).
  5. Réponse Application (HTTP GET → 200 OK).

3. Contributions Principales

1. Méthodologie de décomposition en 5 couches : Une approche novatrice permettant d'isoler l'overhead PQC à des phases spécifiques du protocole, au lieu de se fier uniquement à la latence de bout en bout.
2. Comparaison empirique complète : Analyse comparative directe des configurations classique, hybride et pure PQC sous charge réelle.
3. Découverte clé sur la neutralité algorithmique : Démonstration que la couche de handshake TLS elle-même est largement neutre vis-à-vis de l'algorithme d'échange de clés.
4. Outils et Données Ouverts : Publication d'un outil de réduction de données (pcap_layer_analysis.py) et d'un jeu de données complet (pcaps déchiffrés et logs de clés) pour assurer la reproductibilité.

4. Résultats Clés

A. Décomposition de la Latence par Couche

• Handshake TCP : Indépendant de l'algorithme cryptographique. Aucune différence statistiquement significative n'est observée (latence médiane ~0,36-0,40 ms).
• Délai Client-Side (TCP → TLS) : C'est ici que se concentre l'impact majeur. La latence médiane passe de 0,29 ms (x25519) à ~1,7–1,9 ms pour les configurations PQC (hybrides et pures). Cela représente une augmentation d'environ 6 fois, principalement due à la génération de matériel de clé et à la construction du ClientHello côté client.
• Handshake TLS (ClientHello → Finished) : Contrairement aux attentes, cette couche est algorithmiquement neutre. Les différences de latence entre les configurations sont minimes (0,1 à 0,9 ms) et statistiquement négligeables (taille d'effet Glass's ∆ < 0,33). Les avantages théoriques de ML-KEM (arithmétique parallèle) sont noyés dans le bruit du protocole et du système.
• Couche Application : La latence est dominée par la taille de la réponse et le réseau. L'impact du PQC est négligeable (< 0,74 ms de variation maximale).

B. Surcoût Normalisé (Overhead Factor & Share)

• Facteur de Surcoût (Overhead Factor) : La couche "TCP vers TLS" montre un facteur de ralentissement d'environ 6x. En revanche, le facteur pour le handshake TLS reste proche de 1,0 (parfois même légèrement inférieur pour le PQC pur, mais non significatif).
• Part de Surcoût Cryptographique (COS) : Bien que le coût initial soit élevé, il ne représente que 6 % à 14 % de la latence totale de bout en bout. Les configurations hybrides ont un COS légèrement plus élevé (10,6–14,1 %) que les configurations pures (6,0–7,9 %).

C. Impact de la Taille de la Réponse

• L'augmentation de la taille de la réponse (de 4 Ko à 40 Ko) n'affecte pas les couches cryptographiques (TCP-TLS, Handshake, TLS-App).
• L'overhead PQC absolu reste constant (~2,3 ms), mais sa part relative diminue (de ~15 % à ~8 %) car la latence de transfert de données augmente. Cela suggère que le PQC est moins pénalisant pour les applications transférant de gros volumes de données.

D. Utilisation des Ressources (CPU et Réseau)

• CPU Client : L'utilisation CPU côté client double presque (de ~3,7 % à ~8,5 %) sous charge PQC, ce qui pourrait être un goulot d'étranglement pour les appareils contraints (IoT, mobiles).
• CPU Serveur : L'impact est modeste mais mesurable. Les configurations hybrides augmentent l'utilisation CPU du serveur d'environ 5,8 % par rapport au classique.
• Trafic Réseau : La taille des messages d'échange de clés augmente considérablement (de 32 octets pour x25519 à 1568 octets pour MLKEM1024), mais cela n'a pas d'impact proportionnel sur la latence dans cette architecture.

5. Signification et Conclusion

Cette étude apporte une nuance cruciale à la migration vers le PQC :

1. Le coût n'est pas dans le handshake TLS : L'idée reçue selon laquelle le PQC ralentit massivement la négociation de la session est partiellement fausse. Le handshake TLS lui-même est rapide et neutre.
2. Le coût est dans l'initialisation client : La pénalité principale réside dans la préparation côté client (génération de clés avant l'envoi du ClientHello).
3. Impact global modéré : Pour une transaction HTTP typique, le PQC ajoute seulement 3 à 4 ms de latence totale.
4. Implications pour la migration : Les organisations doivent se concentrer sur la capacité de calcul des clients (et des équipements intermédiaires type MiTM) plutôt que sur la latence pure du serveur. Les configurations hybrides offrent un bon compromis de sécurité sans pénalité de performance excessive par rapport aux configurations pures.

En conclusion, la migration vers TLS 1.3 avec PQC est réalisable avec un impact de performance acceptable, à condition de prendre en compte les ressources clients et de ne pas s'attendre à une dégradation significative de l'expérience utilisateur finale, surtout pour les réponses de taille moyenne à grande.