Auswirkungen von Post-Quanten-Algorithmen auf die Netzwerkleistung

In den ersten beiden Beiträgen dieser Serie habe ich zwei zentrale Post-Quanten-Kryptografie-Vorhaben behandelt: eines zur Absicherung des Schlüsselaustauschs und eines zur Absicherung der Authentifizierung. Auch wenn es sich um zwei unterschiedliche Probleme handelt, haben sie eines gemeinsam: Beide Änderungen wirken sich auf die Leistung verschlüsselter Netzwerkprotokolle aus.

Über die Auswirkungen der Änderungen beim Schlüsselaustausch wird viel gesprochen, doch Google hat lediglich einen geringen Anstieg der Handshake-Latenz beobachtet. Das klingt nicht nach viel, spielt aber im großen Maßstab eine Rolle. Deutlich größere Sorgen bereitet die Größe von Post-Quanten-Signaturen, bei denen die Auswirkungen je nach gewähltem Ansatz weitaus schlimmer ausfallen könnten.

Um zu verstehen, warum das so ist, müssen wir zunächst die grundlegenden Verschlüsselungsprinzipien verstehen und dann, wie TLS sie zur Absicherung nutzt. In diesem Beitrag gehe ich im Detail auf den TLS-Handshake ein und beleuchte die Teile zu Schlüsselaustausch und Authentifizierung sowie die Auswirkungen der Post-Quanten-Änderungen auf diesen entscheidenden Teil der verschlüsselten Kommunikation.

Ganz allgemein wollen wir bei Verschlüsselung vor allem das erreichen, was üblicherweise in drei Aspekten beschrieben wird: Vertraulichkeit, Authentifizierung und Integrität. Um diese Eigenschaften zu erreichen, kombinieren wir kryptografische Primitive zu Protokollen. In jedem kryptografischen Protokoll steckt der Großteil der Komplexität im Handshake, der grob Folgendes leistet:

• Gemeinsame Verschlüsselungsparameter aushandeln
• Authentifizierung durchführen, idealerweise auf beiden Seiten, meist aber nur serverseitig
• Die Verschlüsselungsschlüssel aushandeln (Schlüsselaustausch)
• Die Integrität des Handshakes prüfen, um Manipulationen auszuschließen

Dabei passiert eine ganze Menge. Verbreitete Protokolle müssen zudem Interoperabilität sicherstellen – die Kunst, Hunderte von Tools und Produkten unterschiedlicher Hersteller miteinander sprechen zu lassen, obwohl diese oft mangelhaft implementiert, veraltet oder gar überholt sind.

Die eigentliche Verschlüsselung ist im Vergleich zum Handshake fast schon unspektakulär, vor allem heute, wo sogenannte authentifizierte Verschlüsselung zum Standard gehört. Man gibt im Grunde an, welchen Verschlüsselungsalgorithmus man mit welchem Schlüssel verwenden möchte, füttert ihn mit Eingabedaten und erhält Ausgabedaten zurück. Um Angriffe wie Replay, Umsortierung und Löschung zu verhindern, bilden alle verschlüsselten Datenpakete eine unveränderliche Kette mit gemeinsamer, fortlaufender Integritätsprüfung.

Wir haben bereits festgestellt, wie komplex kryptografische Protokolle sind. Bei TLS besteht ein Handshake aus mehreren Flights. Innerhalb jedes Flights werden mehrere Protokollnachrichten praktisch gleichzeitig von einer Seite zur anderen gesendet. Hier eine einfache Übersicht (ein ausführlicheres detailliertes Diagramm findet sich in der RFC, falls Sie sich dafür interessieren):

1. Der Client startet den Handshake, indem er eine ClientHello-Nachricht sendet.
2. Der Server akzeptiert die Verbindung, wechselt zur Verschlüsselung, sendet sein Zertifikat, weist nach, dass er den passenden privaten Schlüssel besitzt, und schließt den Handshake ab.
3. Der Client validiert die Serverdaten und schließt den Handshake auf seiner Seite ab. Anschließend beginnt er mit dem Senden von Anwendungsdaten (z. B. HTTP).
4. Der Server schließt den Handshake auf seiner Seite ab und antwortet dann auf die Anwendungsdaten.

Betrachtet man den Handshake aus Netzwerksicht, besteht jeder Flight aus einem oder mehreren Netzwerkpaketen, je nachdem, wie viele Daten gesendet werden müssen. Da es Zeit braucht, bis Pakete beim Empfänger ankommen und die Antwort zurückkommt, entsteht zwischen den Flights auch einiges an Wartezeit. Ein vollständiger TLS-Handshake benötigt zwei Roundtrips zwischen Client und Server. Darauf kommen wir später noch zurück.

Jeder Handshake umfasst Folgendes:

• Kryptografische Operationen auf der CPU
• Aufbau der Protokollnachrichten
• Versenden von Bytes über das Netzwerk
• Warten auf die Antwort der Gegenseite
• Verarbeiten der empfangenen Pakete

Wenn Sie mehr erfahren möchten, werfen Sie einen Blick in die kürzlich überarbeitete TLS-1.3-RFC 9846. Danach starten Sie Wireshark und beobachten die tatsächlichen Handshakes, wie sie von Browsern und anderen Tools durchgeführt werden.

Kryptografie bezahlen wir mit erhöhter CPU-Auslastung und Netzwerklatenz. Ersteres lösen wir, indem wir mehr CPU-Leistung einkaufen. Bei Letzterem verlangsamt die Netzwerklatenz unsere Websites, was sich in weniger Umsatz niederschlägt.

Schauen wir uns beide genauer an:

• CPU: In den Anfängen der Kryptografie waren CPUs deutlich langsamer als heute und stellten einen erheblichen Engpass dar. Damals war es üblich, nur einen Teil des Datenverkehrs zu verschlüsseln. Zum Glück ist die Lage heute viel besser, und wir können alles verschlüsseln. Kryptografie hat zwar messbare Kosten, diese fallen aber im Vergleich zum Nutzen kaum ins Gewicht.
• Latenz: Die eigentlichen Kosten der Kryptografie entstehen durch zusätzliche Roundtrips. Für einen TCP-Handshake benötigen wir einen Roundtrip. Wir senden eine Anfrage, die durch das Netzwerk läuft, und warten dann, bis die Antwort zurückkommt. Für einen TLS-Handshake über eine bereits offene TCP-Verbindung benötigen wir zwei weitere Roundtrips. Wer also eine neue Verbindung von London nach New York aufbaut, kommt nicht um 3x90=270 ms reines Warten herum, während die Pakete hin- und herlaufen. QUIC, das auf UDP aufsetzt, kann eine Verbindung schneller öffnen, in nur 180 ms.

Bei Post-Quanten-Kryptografie, die im Kontext von TLS aktuell ML-KEM (für den Schlüsselaustausch) und ML-DSA (Authentifizierung) bedeutet, sind die Unterschiede beim CPU-Bedarf nicht wesentlich anders.

Bei der Netzwerklatenz sieht die Sache ganz anders aus. Sie hat das Potenzial, die Leistung negativ zu beeinflussen, indem sie Bedingungen schafft, die die Anzahl der nötigen Roundtrips während der ersten Handshake-Phase erhöhen. Das kann über einen von zwei Mechanismen geschehen:

• Annahmen zu Key Shares: In TLS 1.3 müssen Clients „raten“, welche Key Shares ein Server unterstützen könnte. Historisch unterstützten alle TLS-1.3-Server X25519, weshalb das alle gesendet haben. Heute senden moderne Clients X25519 sowie X25519MLKEM768, was meist funktioniert. Ist das nicht der Fall, muss der Server über eine HelloRetryRequest-Nachricht einen erneuten Versuch des ClientHello anfordern. Diese Nachricht enthält Informationen darüber, welche Verfahren zum Schlüsselaustausch der Server unterstützt. Unterstützt der Server ein passendes Verfahren, kann er es erneut versuchen – dieser Vorgang fügt aber einen weiteren Roundtrip hinzu.
• Slow Start: Zu Beginn einer neuen Verbindung sind die Netzwerkbedingungen unbekannt, weshalb Protokolle typischerweise langsam starten und die Geschwindigkeit erhöhen, je mehr Pakete ausgetauscht werden. Dieser Ansatz wird in TCP üblicherweise Slow Start genannt, es gibt aber Entsprechungen in anderen Protokollen (z. B. QUIC). Die Datenmenge, die anfangs gesendet werden darf, nennt man das initiale Congestion Window. Der Standardwert für Server liegt heute bei etwa 14,5 KB, wobei CDNs größere Werte erlauben können, zum Beispiel 30–45 KB. Kurz gesagt: Sobald alle erlaubten Daten gesendet wurden, muss man auf eine Antwort warten, was einen weiteren Roundtrip hinzufügt.

Das initiale Congestion Window ist also der neue Engpass. Erinnern Sie sich an meinen früheren Artikel, in dem ich die Größe von Post-Quanten-Signaturen behandelt habe: Ein direkter Übergang von ECDSA- zu ML-DSA-Signaturen in Zertifikaten und Protokollnachrichten könnte dem TLS-Handshake zwischen 14 KB und 18 KB hinzufügen – genug, um das Standard-Congestion-Window der meisten Server komplett zu sprengen.

Zwar lässt sich die Größe des initialen Congestion Windows grundsätzlich erhöhen (sofern unsere Netzwerke das mitmachen), doch müssen wir auch bedenken, dass das Aushandeln von TLS kein Selbstzweck ist – darüber muss noch ein Anwendungsprotokoll gelegt werden. In der Praxis bedeutet das, dass man idealerweise die komplette Homepage der Website auf einen Schlag ausliefern möchte, damit der Browser mit der Verarbeitung beginnen kann.

Neben höheren Kosten und Verlangsamungen führen so grundlegende Änderungen oft auch zu Fehlfunktionen. Das ist zumindest ein Problem, um das wir uns bei der Netzwerkleistung kümmern müssen.

Wie wir gesehen haben, beginnt der Handshake in TLS mit einem ClientHello. In dieser Nachricht übermittelt der Client seine Anfrage an den Server und liefert die Ausgangsparameter. Früher war diese Nachricht recht klein, teils unter 256 Byte. Mit zunehmender Komplexität von TLS wuchs die Größe des ClientHello im Laufe der Jahre, blieb aber innerhalb der Größe eines einzelnen Netzwerkpakets. Dadurch wurde viel Software mit der Annahme geschrieben, dass das gesamte ClientHello stets als ein einziges Paket ankommt.

Diese Annahme brach kürzlich zusammen, als wir den Schlüsselaustausch in TLS um ML-KEM-768 erweiterten, das 1.216 zusätzliche Byte erfordert. Bei der Prüfung eines echten ClientHello habe ich gerade eben 2.117 Byte in der neuesten Chrome-Version beobachtet. Das liegt weit über dem, was in einem einzelnen Paket versendet werden kann (etwa 1.440 Byte an Nutzdaten).

Dadurch durchqueren diese neuen, großen ClientHellos das Netzwerk als zwei TCP-Segmente, und manche Software und Geräte kommen damit aus unterschiedlichen Gründen nicht zurecht. Meist sind es die berüchtigten Middleboxen, Geräte, die den Netzwerkverkehr inspizieren sollen.

TLS hat eine lange Geschichte von Problemen mit Middleboxen. Nahezu jedes Mal, wenn eine Weiterentwicklung des Protokolls nötig war, standen die Middleboxen im Weg. Das führte schließlich zur Entstehung von GREASE, einer Methode, die zufällige Blinddaten einstreut, um Annahmen darüber zu verhindern, was in TLS-Paketen auftauchen darf und was nicht.

Selbst wenn es zu keinem Problem mit zwischengeschalteten Geräten kommt, bedeutet ein größeres ClientHello mehr gesendete Daten und Pakete. Die Kommunikation wird langsamer, und die Wahrscheinlichkeit von Paketverlusten steigt, was zu erneuten Übertragungen führen kann. Das wurde von Google als mediane Zunahme von 4 % der Handshake-Latenz gemeldet. Am Desktop, auf Mobilgeräten noch schlimmer.