Performance der Post-Quanten-Kryptografie

Ich habe bereits ausführlich über die Auswirkungen der Post-Quanten-Kryptografie auf die Netzwerkleistung geschrieben (Links unten). Trotzdem hielt ich es für sinnvoll, einen weiteren Blogbeitrag zu verfassen, um den aktuellen Stand zusammenzufassen, zusätzliche Informationen und Quellen bereitzustellen und vielleicht einige Schlussfolgerungen zu ziehen.

Kurz gesagt: Post-Quanten-Primitive wie ML-KEM und ML-DSA verursachen zwar einen überschaubaren CPU-Mehraufwand, doch ihre deutlich größeren Public Keys und Signaturen stellen reale Netzwerke vor ein erhebliches Payload-Problem. Werden diese größeren Datenmengen durch Transportprotokolle geschleust, kommt es zu Fragmentierung, die üblichen Initial Congestion Windows werden überschritten und zusätzliche Roundtrips ausgelöst, die die Verbindungsgeschwindigkeit direkt verschlechtern.

Dieser Blogbeitrag ist Teil einer Serie. Sie müssen nicht alle bisherigen Teile gelesen haben, sollten aber diese beiden lesen, da sie den relevanten Hintergrund liefern:

• Auswirkungen von Post-Quanten-Algorithmen auf die Netzwerkleistung
• Warum Post-Quantum-Signaturen die TLS-Handshake-Grenzen sprengen

Diese beiden Beiträge konzentrieren sich auf die Theorie, liefern aber, wie Sie feststellen werden, wenig Belege. Was sagen Industrie und Wissenschaft?

Chrome war der erste Browser, der X25519MLKEM768 (ein neues, hybrides, quantensicheres Verfahren zur Schlüsselaushandlung) eingeführt hat. Daher liegt es nahe, dort anzufangen. Was beobachtet das Team in der Praxis?

„Chrome verzeichnete einen Anstieg der TLS-Handshake-Latenz um 4 %, als ML-KEM eingeführt wurde, das etwa 1 KB zusätzlichen Platz im ClientHello beansprucht. Dadurch wurde das ClientHello größer als die übliche Maximum Transmission Unit (MTU) von Paketen im Internet (~1.400 Byte), sodass das ClientHello auf zwei Pakete der darunterliegenden Transportschicht (TCP oder UDP) fragmentiert wurde.“

— David Adrian, aus Post-quantum cryptography is too damn big

Zum selben Thema hat Cloudflare mehrere interessante Blogbeiträge über Post-Quanten-Kryptografie veröffentlicht. Statt die beste Quelle herauszusuchen, verlinke ich hier die gesamte Kategorie. Um Ihnen Zeit zu sparen: Die Ergebnisse decken sich mit denen von Google. Größere Payloads führen zu TCP-Fragmentierung, einer höheren Wahrscheinlichkeit von Paketverlusten und messbaren Verbindungsverzögerungen in realen Netzwerken.

Wer neue kryptografische Payloads und Protokollerweiterungen in freier Wildbahn einführt, stößt unweigerlich auf Middlebox-Ossifikation: Netzwerkgeräte und Sicherheitsinspektionssysteme, die Verbindungen schlicht deshalb abbrechen, weil sie auf Datenstrukturen oder -größen treffen, für die sie nicht programmiert wurden.

Als Google, Cloudflare, Meta und AWS den Einsatz der Post-Quanten-Schlüsselvereinbarung ausweiteten, zeigte sich eine Reihe spezifischer betrieblicher Probleme:

• Ausfälle von Middleboxes und Firewalls: Netzwerkgeräte und Sicherheits-Gateways verwerfen häufig fragmentierte, über mehrere Pakete verteilte ClientHello-Nachrichten oder lehnen unbekannte TLS-Erweiterungen ab. Sophos-Firewalls mit aktivierten Web-Protection-Inspektionsmodi hatten in der Vergangenheit Schwierigkeiten mit Post-Quanten-Client-Handshakes. Gleichzeitig stießen Nutzer der AWS Network Firewall bei der Verarbeitung von PQC-Handshakes mit OpenSSL 3.5.1 auf Fehler beim Rule-Matching.
• Abweichungen bei großflächigen Rollouts: In Metas realem TLS-Deployment (TLS-PQR) führten selbst winzige Intoleranzraten zu Millionen betroffener Nutzerverbindungen. Ähnlich zeigten die umfassenderen PQC-Rollouts von Cloudflare (pqc-to-origin und Post-Quanten für alle), dass Edge-to-Origin- und Client-to-Edge-Pfade auf sehr unterschiedliche Middlebox-Umgebungen treffen.
• Extreme Fragmentierungs-Grenzfälle: Wenn die MTUs von Netzwerkpfaden unter die üblichen Standards fallen oder UDP/QUIC-Handshakes an strikte Amplification-Limits stoßen, lösen große PQC-Nachrichten Drop-Schleifen aus – ein Phänomen, das Forschungsprojekte wie tldr.fail ausführlich dokumentiert haben.

Clients, die mit Servern kommunizieren wollen, die weder X25519 noch X25519MLKEM768 anbieten, müssen ein HelloRetryRequest auslösen. Künftig könnte das Clients betreffen, die eine reine ML-KEM-Schlüsselaushandlung nutzen möchten: Immer wenn der vom Client vorhergesagte Key Share nicht zu den Fähigkeiten des Servers passt, ist ein zusätzlicher Netzwerk-Roundtrip nötig.

In der Zwischenzeit sehen wir ähnliche Probleme bei CDN-Origins: Unterstützt ein Origin die gängigen Verfahren zum Schlüsselaustausch nicht, ist ein zusätzlicher Roundtrip erforderlich, um den Handshake abzuschließen. Cloudflare verfügt über interessante, anderswo nicht verfügbare Daten dazu, welche Verfahren Origins für die Schlüsselaushandlung bevorzugen. In der Untersuchung Automatic Key Exchange for Origins zeigt Cloudflare, wie die dynamische, automatische Aushandlung von Key-Exchange-Präferenzen leistungsmindernde HelloRetryRequest-Roundtrips zwischen Edge-Knoten und Upstream-Origins verhindert.

Dieses Problem sehen wir noch nicht, weil Post-Quanten-Zertifikatsketten selten sind. Wo sie eingesetzt werden, geschieht das über (schnellere) private Netzwerke und bei Clients, die mehr Kontrolle über die Netzwerkeinstellungen haben und ihre TCP-Stacks optimieren können.

Die wissenschaftliche Forschung gibt jedoch einen klaren Ausblick darauf, was passieren könnte, wenn die Post-Quanten-Authentifizierung die öffentliche Web-PKI erreicht:

• Zertifikatsketten und Handshake-Durchsatz: Eine umfassende Performance-Studie von Sikeridis et al. (NDSS 2020) hat NIST-PQC-Signaturkandidaten in TLS-1.3-Zertifikatsketten getestet. Dabei zeigte sich, dass ein einziges großes PQC-Signaturverfahren für die gesamte Kette Serverdurchsatz und Latenz stark verschlechtert. Als Gegenmaßnahme schlugen die Autoren gemischte Zertifikatsketten vor (eine Kombination aus schnellen, größeren Algorithmen wie Falcon und kleineren, langsameren wie Dilithium oder SPHINCS+), die Handshakes deutlich beschleunigen und die Verbindungsraten wiederherstellen.
• Netzwerklatenz vs. CPU-Engpässe: Benchmarking post-quantum cryptography in TLS von Paquin, Stebila und Tam (Microsoft Research) hat mithilfe eines Netzwerkemulations-Frameworks nachgewiesen, dass die CPU-Rechenzeit bei PQC-TLS selten der Hauptengpass ist. Stattdessen dominieren Netzwerklatenz und Paketverluste die Gesamtladezeit, bedingt durch die schiere Größe von Post-Quanten-Public-Keys und -Chiffretexten.
• TTFB und TTLB unter realen Netzwerkbedingungen: Die Forschung von Kampanakis und Childs-Klein (MADWeb 2024) hat den gesamten Verbindungslebenszyklus untersucht, also Time-To-First-Byte (TTFB) und Time-To-Last-Byte (TTLB). Ergebnis: Datenintensive PQC-Zertifikatsketten erhöhen die anfängliche Handshake-Latenz auf störungsfreien Verbindungen zwar um 20–30 %, ihr relativer Einfluss relativiert sich aber stark, wenn große Datenmengen übertragen werden oder die Verbindung ohnehin beeinträchtigt bzw. verlustbehaftet ist.
• White-Box- und Black-Box-Microbenchmarks: Sosnowski et al. (ACM CoNEXT '23) haben gezeigt, dass gitterbasierter Schlüsselaustausch auf der CPU zwar schneller ausgeführt wird als klassische Algorithmen, die größeren Schlüssel und Zertifikatsketten auf verlustbehafteten Netzwerkpfaden jedoch die Latenz auf Netzwerkebene erhöhen.

Verlässt man die Welt der Desktop-Browser und leistungsstarken Edge-Server und wendet sich Hardware-Sicherheitsmodulen (HSMs), IoT-Mikrocontrollern und eingebetteten Systemen zu, führen der hohe Speicherbedarf und die großen Paketgrößen von PQC zu erheblichen physischen Einschränkungen.

Gängige IoT-Protokolle (wie CoAP, DTLS und EDHOC) laufen über verlustbehaftete, energiesparende Funknetzwerke, deren Paketpuffer in Kilobyte gemessen werden. Das Speichern und Zusammensetzen von mehreren Kilobyte großen PQC-Public-Keys oder -Signaturen führt schnell zu erschöpften Puffern, Schleifen durch verlorene Fragmente und starkem Batterieverbrauch. Hinzu kommt, dass HSMs und Smartcards bei der Verwaltung von PQC-Schlüsselmaterial und der Verarbeitung umfangreicher OTA-Firmware-Signaturen (Over-The-Air) mit knappem nichtflüchtigem Speicher und begrenzter interner Busbandbreite zu kämpfen haben.

Die IETF arbeitet aktiv an technischen Lösungen, um ressourcenbeschränkte Umgebungen an die Post-Quanten-Anforderungen anzupassen:

• RFC 9958: Post-Quantum Cryptography for Engineers: Dieses von der PQUIP-Arbeitsgruppe veröffentlichte Dokument beschreibt betriebliche Leitlinien, Performance-Abwägungen und Kriterien für die Algorithmenauswahl bei ressourcenbeschränkten Netzwerk-Stacks.
• draft-ietf-pquip-pqc-hsm-constrained: Befasst sich mit den Grenzen physischer Hardwareressourcen und beschreibt, wie Zustands-, RAM- und NVRAM-Beschränkungen in HSMs, Smartcards und eingebetteten Mikrocontrollern die Speicherung von PQC-Schlüsseln, Verarbeitungszeiten und Firmware-Updates beeinflussen.
• draft-rfcxml-pqc-key-fragmentation: Analysiert Risiken beim Zusammensetzen auf Netzwerkebene und gibt Empfehlungen, um erschöpfte Puffer und Paketverlust-Schleifen bei der Übertragung fragmentierter PQC-Schlüssel über energiesparende Funknetzwerke (CoAP, DTLS, EDHOC, OSCORE) zu vermeiden.
• Kompakte und zustandsbehaftete Signaturen: Leitlinien zum Einsatz zustandsbehafteter hashbasierter Signaturverfahren (wie LMS und XMSS, definiert in RFC 8554 / RFC 8708), damit Verifizierungscode und Aufwand für die Signaturprüfung schlank genug für eingebettete Bootloader bleiben.

Wir haben viele Probleme, aber die eigentliche Rechenleistung gehört nicht dazu. Die modernen gitterbasierten PQC-Algorithmen, insbesondere ML-KEM und ML-DSA, sind rechnerisch schnell. Auf modernen x86- und ARM-Prozessoren benötigen gitterbasierte Schlüsselerzeugung, Kapselung und Entkapselung oft weniger CPU-Zyklen als ein herkömmlicher ECDH- oder RSA-Austausch. Zum Glück müssen wir uns darüber zumindest keine Sorgen machen – es sei denn, wir wechseln künftig zu anderen Algorithmen.

Trotz dieser strukturellen Hürden argumentieren mehrere empirische Benchmarks, dass Post-Quanten-TLS das Internet nicht lahmlegen wird und die Performance an unerwarteten Stellen sogar verbessern könnte:

• Rechnerische Überlegenheit gleicht die Datenmenge aus: Sosnowski et al. (ACM CoNEXT '23) haben gezeigt, dass der Gesamtdurchsatz von Servern unter normalen Netzwerkbedingungen sogar steigen kann, weil gitterbasierte Primitive (ML-KEM) drastisch weniger CPU-Zyklen benötigen als klassische Kurven mit hoher Sicherheitsstufe oder RSA.
• Mikrocontroller können mit PQC sogar schneller laufen: Gillot, Buchanan und Turino (arXiv:2610.27766) haben die Annahme, IoT-Hardware würde unter PQC-Payloads einknicken, direkt infrage gestellt. Bei Tests mit Dutzenden TLS-1.3-Konfigurationen auf ressourcenbeschränkten Mikrocontrollern (etwa dem Raspberry Pi Pico W) stellten sie fest, dass Post-Quanten-TLS-Handshakes dank der zyklusarmen mathematischen Operationen von ML-KEM deutlich schneller abgeschlossen wurden (in Benchmarks bis zu ~41 % schneller) als klassische Handshakes. Damit belegen sie, dass eingebettete Geräte quantensicheren Schlüsselaustausch problemlos bewältigen können.
• Amortisierung der Payload im realen Datenverkehr: Die Forschung von Kampanakis & Childs-Klein (MADWeb '24) zeigt: Zwar steigt die PQC-Handshake-Latenz isoliert betrachtet, sie wird jedoch statistisch vernachlässigbar, wenn man sie anhand der realen Time-to-Last-Byte (TTLB) und typischer HTTP-Payloads (>40 KB) bewertet.
• Architektonische Lösungen wie KEMTLS: Die Forschung von Schwabe, Stebila und Wiggers (ACM CCS '20) belegt, dass Authentifizierung nicht zwingend mehrere Kilobyte große Signaturen erfordert: Ersetzt man Handshake-Signaturen durch KEMs (AuthKEM), bleibt die Datenmenge des Handshakes deutlich innerhalb der üblichen TCP-Window-Grenzen.