Es kommt regelmäßig die Frage auf, was Post-Quantum-Pakete eigentlich kosten. Ein klassischer TLS-1.3-Handshake umfasst vier bis sechs Kilobyte auf der Leitung. Dieselbe Verbindung mit hybridem ML-KEM-Schlüsselaustausch und ML-DSA-Zertifikatssignaturen erreicht fünfzehn bis zwanzig. Dieser Unterschied wirkt sich auf TCP, QUIC und IP-Fragmentierung aus, und er verändert, wie Kapazität, Timeouts und Middlebox-Toleranz geplant werden müssen, bevor hybride PQC in die Produktion kommt.
Die Zahlen sind bislang über NIST-Spezifikationen, Engineering-Blogs und wissenschaftliche Arbeiten verstreut. Dieser Beitrag bietet einen einzigen Ort, der die Diskussion voranbringt, für alle, die die Referenz brauchen. Er kommt mit einem Rechner für alle, die sehen wollen, was ein konkreter Stack auf der Leitung verändert.
Rohgrößen, eine Tabelle
Beiträge des Schlüsselaustauschs. Die Summe auf der Leitung ist der Client Key Share plus Server Key Share, also das, was dem TLS-1.3-Handshake hinzugefügt wird, wenn der KEM ausgewählt wird.
| Schlüsselaustausch | Client Key Share | Server Key Share | Gesamt auf der Leitung |
|---|---|---|---|
| X25519 | 32 | 32 | 64 |
| P-256 ECDHE (unkomprimiert) | 65 | 65 | 130 |
| ML-KEM-512 | 800 | 768 | 1.568 |
| ML-KEM-768 | 1.184 | 1.088 | 2.272 |
| ML-KEM-1024 | 1.568 | 1.568 | 3.136 |
| X25519MLKEM768 (hybrid) | 1.216 | 1.120 | 2.336 |
| P256MLKEM768 (hybrid) | 1.249 | 1.153 | 2.402 |
Beiträge der Signaturen. Jede Signatur in einer TLS-Zertifikatskette trägt einen öffentlichen Schlüssel plus eine Signatur bei. Eine typische Kette enthält eine Leaf-Signatur, eine Zwischensignatur und SCT-Signaturen aus Certificate-Transparency-Logs. Die Root ist lokal im Trust Store verankert und wandert nicht über die Leitung. Klassische öffentliche Schlüssel sind unten als SubjectPublicKeyInfo DER angegeben, also in der Form, in der sie tatsächlich in einem X.509-Zertifikat ausgeliefert werden; PQC-Rohschlüssel sind bereits die On-Wire-Form.
| Signaturverfahren | Öffentlicher Schlüssel | Signatur | Pro Ketteneintrag |
|---|---|---|---|
| Ed25519 | 44 | 64 | 108 |
| ECDSA-P256 | 91 | 72 | 163 |
| RSA-2048 | 294 | 256 | 550 |
| ML-DSA-44 | 1.312 | 2.420 | 3.732 |
| ML-DSA-65 | 1.952 | 3.309 | 5.261 |
| ML-DSA-87 | 2.592 | 4.627 | 7.219 |
| Falcon-512 (FN-DSA) | 897 | 666 Mittel | 1.563 Mittel |
| Falcon-1024 | 1.793 | 1.280 Mittel | 3.073 Mittel |
| SLH-DSA-128s | 32 | 7.856 | 7.888 |
| SLH-DSA-128f | 32 | 17.088 | 17.120 |
| SLH-DSA-192f | 48 | 35.664 | 35.712 |
Alle Größen in Bytes. Quellen: NIST FIPS 203, 204, 205 und der Entwurf FIPS 206 für FN-DSA sowie RFC 5280 für die X.509-SPKI-Darstellung klassischer Schlüssel. Falcon-Signaturen sind pro Signatur variabel lang; der angegebene Wert ist das veröffentlichte Mittel. Diese Werte entsprechen den Konstanten, die der Handshake-Größenrechner verwendet.
Wie ein vollständiger Handshake aussieht
Ein klassischer TLS-1.3-Handshake mit X25519 für den Schlüsselaustausch und einer ECDSA-P256-Leaf, signiert über eine RSA-2048-Zwischeninstanz, läuft mit etwa 4 bis 6 KB auf der Leitung. Der größte einzelne Beitrag ist die Zertifikatskette mit 2 bis 3 KB.
Wechselt man zu X25519MLKEM768 für den Schlüsselaustausch, wächst der Handshake um etwa 2,3 KB. Die ClientHello-Erweiterung key_share wächst von 32 Bytes auf 1.216 Bytes. Die key_share-Antwort des Servers wächst von 32 Bytes auf 1.120 Bytes. Der Overhead des Schlüsselaustauschs ist real, aber er ist der kleinere der beiden PQC-Beiträge.
Wechselt man die Zertifikatskette auf ML-DSA-65-Signaturen, bewegen sich die Zahlen anders. Eine Kette mit zwei Signaturen (Leaf plus Zwischeninstanz) trägt rund 10 KB Authentifizierungsdaten, wo klassisch etwa 150 Bytes anfielen. Fügt man SCTs aus Certificate Transparency hinzu, jede mit eigener Signatur, erreicht die Gesamtgröße des Handshakes 17 bis 20 KB.
Hashbasierte Signaturen sind noch größer. Eine einzelne SLH-DSA-192f-Signatur ist 35.664 Bytes für sich allein. Eine einzelne SLH-DSA-Signatur in einer Kette überschreitet die gesamte Handshake-Größe vor PQC.
Die Netzwerkgrenzen, die die neuen Größen überschreiten
Das initiale TCP-Congestion-Window nach RFC 6928 beträgt 10 Maximum Segment Sizes, also etwa 14,6 KB bei einer Standard-MSS von 1460 Bytes. Ein klassischer Handshake passt beim ersten Flug in IW10. Ein hybrider Handshake mit ML-DSA tut das oft nicht, und der Server wartet eine volle Round-Trip-Zeit auf die Bestätigung des Clients, bevor er den Rest sendet. Diese zusätzliche RTT ist der Performance-Preis, den die meisten Teams erst beim Deployment sehen.
QUIC erzwingt ein 3x-Amplifikationslimit vor der Adressvalidierung des Clients. Ein Server-Initial-Flug, der größer ist als das Dreifache des Client-Initials (mindestens 3.600 Bytes), wird auf mehrere Sendungen aufgeteilt, und der Server kann den vollständigen Flug erst nach abgeschlossener Validierung freigeben. Zertifikatsketten in ML-DSA-Größe überschreiten diese Grenze trivial.
Die Ethernet-MTU bleibt bei 1.500 Bytes. Jedes zusätzliche Kilobyte im Handshake erhöht die Paketzahl und steigert das Fragmentierungsrisiko an Middleboxen, die TLS neu segmentieren. Manche Middleboxen verwerfen TLS-Records über 16 KB kategorisch.
DNSSEC über UDP mit dem typischen EDNS-Puffer von 1.232 Bytes kann kein PQC-Signaturmaterial transportieren. Eine mit ML-DSA signierte Zone erzwingt TCP-Fallback oder IP-Fragmentierung bei jeder Abfrage.
Planen mit Ihrer eigenen Konfiguration
Die Rohtabellen sind eine Referenz. Die Wechselwirkung, die zählt, ist das, was passiert, wenn Sie KEM, Signaturverfahren, Kettentiefe und SCT-Anzahl zusammen wählen.
Der pqprobe-Handshake-Größenrechner nimmt diese Eingaben und liefert die vollständige Größe des Server-zu-Client-Flugs, den Spielraum oder Überlauf bei IW10 und IW20, die Prüfung auf QUIC-Amplifikation und eine geschätzte Paketzahl bei Standard-MSS.
Wie Endpunkte heute tatsächlich aussehen
Die Größen in den Tabellen sind Obergrenzen unter der Annahme, dass jede Schicht PQC ist. Reale Deployments befinden sich mitten im Übergang. Viele Sites haben hybriden Schlüsselaustausch aktiviert und behalten klassische Zertifikatsketten bei, was etwa 2,3 KB zum Handshake hinzufügt, ohne die ML-DSA-Kosten zu erreichen. Andere haben ML-DSA-Zertifikate in der privaten PKI eingeführt und liefern öffentlich weiterhin klassische Ketten aus. Welche Schichtkombination ein konkreter Endpunkt fahrät, lässt sich messen.
Wiederholte Messung über eine Flotte hinweg ist ein nützlicher Input für die Migrationsplanung. Sie zeigt, welche Endpunkte welche Schichten bewegt haben, und wie sich „unterstützt PQC“ und „verhandelt PQC“ unterscheiden, in Bytes für den eigenen Stack. tshark, Zeek, interne Sonden oder ein Scanner wie pqprobe liefern alle Handshake-Inhalte; die Wahl hängt davon ab, was das Team bereits betreibt.
Planungshinweise
Netzwerk-Teams profitieren davon, den IW10-Spielraum vor einem hybriden Rollout zu messen. Eine Flotte, die klassische Flüge bequem in einer RTT unterbringt, muss hybride Flüge nicht zwingend unterbringen, und die zusätzliche RTT summiert sich bei jeder neuen Verbindung, die keine bestehende Session wiederverwendet. Die Zahl pro Endpunkt zu kennen, erlaubt es, vorab dafür zu budgetieren oder eine Konfiguration zu wählen, die innerhalb des Fensters bleibt.
Entwickler, die Signaturverfahren für PQC-Workloads auswählen, haben einen echten Tradeoff zwischen Größenspalte und Algorithmusspalte. ML-DSA-44 ist die Untergrenze für NIST-Konformität. Falcon bietet kleinere Signaturen, bezahlt das jedoch mit höherer Implementierungskomplexität bei Seitenkanälen. SLH-DSA ist konservativ gegen zukünftige Kryptoanalyse, aber schwer auf der Leitung. Die richtige Wahl hängt von Session-Wiederverwendung, Middlebox-Verhalten und dem Verbindungsvolumen am jeweiligen Endpunkt ab.
Hybride PQC ist eine Zwischenstation auf dem Weg zu reiner PQC, und die Byte-Zahlen werden voraussichtlich von hier aus weiter wachsen. Die Messung der Handshake-Größe pro Endpunkt eröffnet die Diskussion, ob der nächste Migrationsschritt eine Konfigurationsänderung ist oder etwas eher im Bereich einer Netzwerkänderung liegt, und beides plant sich leichter mit Zahlen in der Hand.
Die PQC-Migration ist ebenso ein Thema der Performance-Optimierung wie ein kryptographisches. Die Handshake-Größe pro Endpunkt vor und nach einer Umstellung zu messen, liefert eine konkrete Zahl zum Planen und eine Möglichkeit zu prüfen, ob die Änderung das geliefert hat, was das Design annahm.