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

Diese Studie analysiert im Laborumfeld die Auswirkungen von klassischen, hybriden und reinen postquantenkryptografischen Schlüsselaustauschverfahren auf die verschiedenen Ebenen von TLS 1.3-Handshakes und HTTP-Transaktionen unter Last.

Das Wesentliche

🛡️ Der große Test: Wie gut funktioniert der neue "Quanten-Schutz" im Internet?

Stellen Sie sich vor, das Internet ist eine riesige Autobahn, auf der Autos (Ihre Daten) fahren. Damit diese Autos sicher ankommen, gibt es an jeder Einfahrt eine Sicherheitskontrolle. Diese Kontrolle heißt TLS-Handshake.

Bisher nutzten wir eine alte, bewährte Methode, um die Autos zu überprüfen (das nennen die Forscher "klassisch"). Aber es gibt eine neue Bedrohung: Quantencomputer. Diese sind wie superschnelle Diebe, die in der Zukunft die alten Schlösser knacken könnten. Deshalb bauen wir gerade neue, extrem robuste Schlösser ein, die man mit herkömmlichen Computern nicht knacken kann. Das nennt man Post-Quanten-Kryptografie (PQC).

Die Frage dieser Studie war: Macht der Einbau dieser neuen, super-sicheren Schlösser den Verkehr langsamer?

Die Forscher haben das nicht nur theoretisch berechnet, sondern es in einem riesigen Labor nachgebaut. Sie haben eine Autobahn simuliert, auf der 100 Autos pro Sekunde durch die Kontrolle mussten. Sie haben drei Szenarien getestet:

1. Das alte Schloss (Klassisch).
2. Das alte Schloss + ein neues Schloss (Hybrid – eine Art Übergangslösung).
3. Nur das neue, riesige Schloss (Rein Post-Quantum).

Hier sind die wichtigsten Erkenntnisse, übersetzt in einfache Bilder:

1. Die "Vorbereitungszeit" ist der Flaschenhals 🏃‍♂️💨

Stellen Sie sich vor, bevor ein Auto zur Sicherheitskontrolle fährt, muss der Fahrer erst seinen Schlüsselbund zücken und den Schlüssel in die Hand nehmen.

• Das Ergebnis: Bei den neuen Quanten-Schlössern dauert es deutlich länger, den Schlüssel zu finden und zu halten.
• Der Vergleich: Bei der klassischen Methode dauert diese Vorbereitung nur einen Wimpernschlag (ca. 0,3 Millisekunden). Bei den neuen Quanten-Schlössern dauert es etwa sechsmal so lange (ca. 1,8 Millisekunden).
• Warum? Der Computer des Fahrers (der Client) muss viel mehr Rechenaufwand betreiben, um den riesigen neuen Schlüssel zu generieren. Das ist der einzige Teil, der wirklich spürbar langsamer wird.

2. Der eigentliche Check ist überraschend schnell! 🚦

Sobald der Fahrer den Schlüssel in der Hand hat und zur Schranke kommt, passiert etwas Überraschendes.

• Das Ergebnis: Die eigentliche Sicherheitskontrolle (der "TLS-Handshake") dauert bei allen drei Methoden fast genau gleich lang.
• Die Metapher: Es ist, als ob die Sicherheitsbeamten an der Schranke den neuen, riesigen Schlüssel genauso schnell prüfen wie den alten kleinen. Die neue Technologie ist so effizient programmiert, dass sie im "Echtzeit-Verkehr" keinen Unterschied macht.
• Wichtig: Viele Leute dachten, die neuen Schlösser wären so schwer, dass die Schranke langsamer öffnen würde. Die Studie zeigt: Nein, das ist ein Mythos.

3. Die Größe des Pakets spielt keine Rolle 📦

Die Forscher haben auch getestet, ob es einen Unterschied macht, ob das Auto ein kleines Paket (4 KB) oder einen riesigen Container (40 KB) transportiert.

• Das Ergebnis: Die extra Zeit, die für das neue Schloss nötig ist, bleibt immer gleich (sie ist "fest").
• Der Effekt: Wenn das Paket sehr groß ist (viele Daten), wird die Reisezeit ohnehin länger, weil das Paket einfach mehr Platz braucht. Der kleine Zeitverlust durch das neue Schloss "verwässert" sich dann.
• Vergleich: Wenn Sie 10 Minuten für eine große Pizza brauchen, macht 10 Sekunden extra Zeit für das neue Schloss kaum einen Unterschied. Wenn Sie aber nur eine kleine Pizza in 10 Sekunden holen, fallen die 10 Sekunden mehr auf.

4. Wer wird müde? Der Fahrer, nicht die Polizei 🤯

Die Studie hat auch gemessen, wie viel Arbeit die Computer leisten müssen.

• Der Fahrer (Ihr Gerät/Smartphone): Er muss viel mehr arbeiten. Seine CPU (der Motor) wird bei den neuen Schlössern etwa doppelt so stark belastet. Für alte Handys oder kleine IoT-Geräte könnte das ein Problem sein.
• Die Polizei (Der Server): Die Server im Hintergrund müssen nur ein bisschen mehr arbeiten (ca. 5–6 % mehr). Das ist wie ein Polizist, der ein bisschen schneller läuft, aber nicht erschöpft ist.

🏁 Das Fazit in einem Satz

Der Einbau von Quanten-Schutz im Internet kostet Sie etwas mehr Zeit beim Start (beim Zücken des Schlüssels), aber sobald die Verbindung steht, ist alles so schnell wie vorher.

Was bedeutet das für uns?

• Keine Panik: Das Surfen im Internet wird nicht spürbar langsamer.
• Vorbereitung: Wir müssen uns darauf einstellen, dass unsere Geräte (besonders kleine oder alte) etwas mehr Energie verbrauchen, um die neuen Schlüssel zu verwalten.
• Zukunftssicher: Wir können jetzt schon auf die neuen Schlösser umsteigen, ohne dass der Verkehr auf der Autobahn zum Erliegen kommt.

Die Studie sagt uns also: Es lohnt sich, den Umzug zu wagen, auch wenn das Umzugskartonschleppen am Anfang etwas anstrengender ist.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange" auf Deutsch.

1. Problemstellung und Hintergrund

Die bevorstehende Verfügbarkeit kryptografisch relevanter Quantencomputer bedroht die Sicherheit aktueller Public-Key-Infrastrukturen (z. B. ECDH, RSA). Um dem „Store Now, Decrypt Later"-Angriff vorzubeugen, hat das NIST im August 2024 die ersten Post-Quantum-Kryptografie-Standards (PQC) finalisiert, darunter FIPS 203 (ML-KEM).

Bisherige Studien haben die Performance-Auswirkungen von PQC oft nur auf aggregierter Ebene (Gesamt-Handshake-Zeit) untersucht. Es fehlte jedoch eine differenzierte Analyse, die genau bestimmt, in welcher Phase des TLS-1.3-Transaktionsflusses die durch PQC verursachten Latenzkosten entstehen. Dies ist entscheidend für die Planung einer Migration in Produktionsumgebungen, insbesondere unter Last.

2. Methodik und Experimentelles Setup

Die Autoren entwickelten eine Laborarchitektur, die eine reale Umgebung emuliert, um die Auswirkungen von PQC auf fünf verschiedene Schichten einer HTTP-over-TLS-Transaktion zu analysieren:

1. TCP-Handshake (SYN bis SYN-ACK)
2. TCP-zu-TLS-Verzögerung (SYN-ACK bis ClientHello)
3. TLS-Handshake (ClientHello bis Finished)
4. TLS-zu-Anwendungs-Verzögerung (Finished bis HTTP GET)
5. Anwendungsantwort (HTTP GET bis HTTP 200 OK)

Experimenteller Aufbau:

• Lastgenerator: Keysight CyPerf (Client-Agent), der 100 Transaktionen pro Sekunde (TPS) generiert.
• Server: Nginx 1.27.3 als Reverse Proxy, kompiliert mit OpenSSL 3.4.0 und dem OQS-Provider (Open Quantum Safe) für PQC-Unterstützung.
• Backend: Ein weiterer CyPerf-Agent, der die HTTP-Antworten generiert.
• Konfigurationen: Vergleich von klassischen (x25519), hybriden (x25519 + ML-KEM) und reinen PQC-Verfahren (ML-KEM 512/1024).
• Variablen: Unterschiedliche Antwortgrößen (4 KB und 40 KB) zur Isolierung kryptografischer Kosten von Übertragungskosten.
• Datenerfassung: Vollständige Paketmitschnitte (pcap) mit SSLKEYLOGFILE zur Entschlüsselung und schichtenweisen Latenzanalyse mittels eines benutzerdefinierten Python-Skripts.

3. Hauptbeiträge

1. Fünfschichten-Latenzzerlegung: Eine neue Methodik zur Aufteilung der End-to-End-Latenz in fünf Protokollphasen, um PQC-Overhead präzise zuzuordnen.
2. Umfassender Vergleich: Empirischer Vergleich von klassischen, hybriden und reinen PQC-Konfigurationen unter realistischer Last (100 TPS) über mehr als 30 Experimente (ca. 1 Million Anfragen).
3. Erkenntnis zur Algorithmus-Neutralität: Nachweis, dass die TLS-Handshake-Schicht selbst algorithmusneutral ist; PQC verursacht hier keine praktisch messbaren Nachteile.
4. Open Source: Bereitstellung eines Tools zur Datenreduktion aus Paketmitschnitten sowie eines öffentlichen Datensatzes mit entschlüsselten TLS-Paketen für reproduzierbare Analysen.

4. Wichtige Ergebnisse

A. Schichtenspezifische Analyse

• TCP-Handshake: Unbeeinflusst vom kryptografischen Algorithmus (Median-Latenz ~0,36–0,40 ms).
• TCP-zu-TLS-Verzögerung (Client-Initialisierung): Dies ist die kritische Schwachstelle. Die Latenz steigt von ~0,3 ms (klassisch) auf ~1,8–1,9 ms (PQC). Dies entspricht einem 6-fachen Overhead (Glass's ∆ ≈ 7,7). Der Hauptgrund ist die clientseitige Generierung von Schlüsselmaterial und die Konstruktion des ClientHello.
• TLS-Handshake: Überraschenderweise zeigt diese Schicht keine signifikanten Unterschiede. Die Latenzunterschiede zwischen klassischen und PQC-Verfahren liegen im Bereich von 0,1–0,9 ms und sind statistisch nicht signifikant (∆ < 0,33). Die theoretische Effizienz von ML-KEM wird durch Protokoll-Framing und System-Jitter auf dieser Ebene ausgeglichen.
• Anwendungsschicht: Die Antwortzeit wird fast ausschließlich durch die Netzwerklatenz und die Payload-Größe bestimmt. PQC hat hier keinen messbaren Einfluss.

B. Normalisierter Overhead

• Overhead Factor (OF): Der TCP-zu-TLS-Layer zeigt einen Faktor von ca. 6x. Der TLS-Handshake bleibt bei ca. 1,0.
• Cryptographic Overhead Share (COS): Trotz des hohen Overheads in der Initialisierungsphase macht der gesamte PQC-Overhead nur 6–14 % der gesamten Verbindungszeit aus. Hybride Konfigurationen liegen hier leicht höher (10,6–14,1 %) als reine ML-KEM (6,0–7,9 %).

C. Einfluss der Payload-Größe

• Bei Erhöhung der Antwortgröße von 4 KB auf 40 KB bleibt der kryptografische Overhead absolut konstant.
• Da die Gesamtlatenz durch die größere Datenmenge steigt, verringert sich der relative PQC-Overhead von ca. 15 % (bei 4 KB) auf ca. 8 % (bei 40 KB).

D. Ressourcenverbrauch (CPU & Netzwerk)

• Client-CPU: Verdoppelt sich unter PQC (von ~3,7 % auf ~8,2–8,7 %). Dies ist ein kritischer Faktor für ressourcenbeschränkte Geräte (IoT, Mobile).
• Server-CPU: Zeigt nur eine moderate relative Zunahme (bis zu +5,8 % bei Hybriden), bleibt aber absolut niedrig (~14–15 %).
• Netzwerk: Der Datenverkehr steigt linear mit der Schlüssellänge (von 32 Byte auf bis zu 1568 Byte), hat aber keinen proportionalen Einfluss auf die Latenz.

5. Bedeutung und Fazit

Die Studie widerlegt die Annahme, dass PQC-Implementierungen zwangsläufig zu einer signifikanten Verlangsamung des gesamten TLS-Handshakes führen.

• Haupttreiber: Der Performance-Impact ist fast ausschließlich auf die Client-seitige Initialisierung (TCP-zu-TLS) beschränkt.
• Handshake: Der eigentliche TLS-Handshake ist algorithmusneutral; reine PQC-Verfahren verursachen keine messbare Strafe im Vergleich zu klassischen Verfahren.
• Migration: Für die Migration zu PQC bedeutet dies, dass die größten Herausforderungen bei ressourcenbeschränkten Clients und bei Netzwerkgeräten liegen, die als Man-in-the-Middle (MiTM) agieren und den Verkehr entschlüsseln müssen. Bei Servern mit hoher Last und großen Payloads ist der relative Performance-Einbruch gering.

Die Autoren empfehlen, zukünftige Tests auf reale Netzwerkumgebungen mit kommerziellen Load Balancern und MiTM-Geräten sowie auf höhere Lastlevel (>100 TPS) und digitale Signaturalgorithmen (ML-DSA, SLH-DSA) auszudehnen.