Die Kosten des quantensicheren Webs
Die Kosten des quantensicheren Webs
Kryptografische Migrationen können langwierig sein, aber gut designte Protokolle mit «Crypto-Agility» machen den Übergang reibungslos. Viele Nutzerinnen und Nutzer haben wahrscheinlich gar nicht bemerkt, dass heute praktisch jeder Browser einen quantensicheren Schlüsselaustausch für jede HTTPS-Verbindung anbietet, während nur etwa die Hälfte der Top-Million-Websites ihn beantwortet.
In unserem vorherigen Beitrag haben wir erklärt, warum Harvest-now-decrypt-later-Angriffe (HNDL) den Schlüsselaustausch ganz nach vorne in die Post-Quantum-Kryptografie stellen. Heute aufgezeichnete Daten lassen sich entschlüsseln, sobald ein kryptografisch relevanter Quantencomputer existiert. Daten, die über Jahre geheim bleiben müssen, sind damit bereits heute exponiert. TLS sichert nahezu das gesamte Internet, und es ist eines der ersten Protokolle, das im grossen Massstab post-quantum geht. Es ist eine der grössten Kryptografie-Migrationen, die laufen, und der beste Produktions-Beweis dafür, was Post-Quantum-Kryptografie kostet.
Wo das Quantenrisiko in TLS sitzt
TLS bietet verschiedenen Schutz für «Web-Traffic». Es authentifiziert die Parteien und beweist, dass die aufgerufene Seite wirklich von Ihrer Bank kommt, und es verschlüsselt den Traffic, sodass Ihr Netzwerkanbieter das eingegebene Passwort nicht sieht. Dieser Beitrag dreht sich um die Verschlüsselung. Authentifizierung und der bevorstehende Wechsel von X.509 zu Merkle Tree Certificates (MTCs) folgen in einem späteren Beitrag.
TLS-Verschlüsselung funktioniert in zwei Schritten. Client und Server vereinbaren zuerst ein gemeinsames Geheimnis und verwenden es dann, um alles mit einer symmetrischen Chiffre wie AES zu verschlüsseln. Die symmetrische Verschlüsselung ist gegen Quantenangriffe bereits sicher. Der Schlüsselaustausch ist es nicht. Genau den bricht ein Quantencomputer.
Wir haben uns auf TLS 1.3 konzentriert, die einzige Version mit einem quantensicheren Schlüsselaustausch. Der Client startet mit einem ClientHello, in dem er mehrere Key-Exchange-Algorithmen vorschlägt und zu jedem seinen Teil des Austauschs beilegt. Der Server wählt einen aus, berechnet seinen eigenen Teil und schickt ihn im ServerHello zurück. Dieses Design macht TLS crypto-agile. Ein Server kann einen Post-Quantum-Schlüsselaustausch hinzufügen, ohne ältere Clients zu brechen. Er wählt die Post-Quantum-Option, wenn ein moderner Client sie anbietet, und fällt für «Legacy-Clients» auf die klassische zurück.
Ein hybrider Schlüsselaustausch
Der TLS-Schlüsselaustausch lief jahrelang meist über elliptic-curve Diffie-Hellman mit X25519. Es ist schnell, die «Key Shares» sind winzig, aber es ist nicht post-quantum-sicher. Der Ersatz ist X25519MLKEM768, eine hybride Konstruktion, die X25519 behält und ML-KEM daneben laufen lässt, den Post-Quantum-Key-Encapsulation-Standard, den NIST 2024 veröffentlicht hat.
X25519 und ML-KEM erzeugen je ein gemeinsames Geheimnis, und TLS kombiniert beide. Der Schlüsselaustausch bleibt sicher, solange eines von beiden hält. Ein Quantencomputer, der X25519 bricht, reicht nicht, und eine zukünftige Schwäche in ML-KEM ebenfalls nicht. Dieses Sicherheitsnetz kostet fast nichts an Rechenleistung. Der Preis liegt in der Grösse, mit Key Shares, die mehr als dreissigmal grösser sind:
Alle modernen Browser unterstützen diesen Schlüsselaustausch inzwischen. Firefox 132 aktivierte X25519MLKEM768 im Oktober 2024 als Standard, Chrome 131 folgte im November 2024. Edge, Brave und Opera erben es von Chromium, und Apple schaltete es in Safari mit iOS 26 und macOS 26 im September 2025 ein. Stand September 2026 zeigt Cloudflare Radar, dass rund drei Viertel des Schweizer Web-Traffics zu Cloudflare von Clients stammen, die einen Post-Quantum-Schlüsselaustausch anfordern.
Die Server hinken hinterher. In Jan Schaumanns Crawl vom September 2026 unterstützte nur die Hälfte der Top-Million-Websites einen Post-Quantum-Schlüsselaustausch. Wer eigene Websites hostet, hat Besucherinnen und Besucher, die bereits mehrheitlich einen quantensicheren Schlüsselaustausch anfordern. Ob sie einen bekommen, hängt von Ihrer «Edge-Konfiguration» ab.
Was es kostet
Wir haben echte «Handshakes» gegen einen HTTPS-Endpunkt im Echtbetrieb über TCP und QUIC gemessen, die beiden «Transports», die heute HTTPS tragen. Client, Server und Netzwerkpfad blieben fix. Wir haben nur die Post-Quantum-Gruppe auf jeder Seite umgeschaltet, was vier Konfigurationen ergibt. Die angegebenen Grössen umfassen alles bis zu den ersten Applikationsdaten, inklusive der TCP-Handshake-Bytes, wo anwendbar:
- Klassisch. Keine der beiden Seiten bietet die Hybridgruppe an.
- Nur Client. Der Client schlägt die Hybridgruppe vor, der Server unterstützt sie nicht.
- Nur Server. Umgekehrt.
- Beide mit PQC. Beide Seiten unterstützen X25519MLKEM768.
Handshake-Grösse auf der Leitung
Bytes sind der Ort, an dem PQC etwas kostet. Voller PQC wächst der Handshake um 2,6 KB auf beiden Transports, von 3,3 KB auf 5,9 KB über TCP und von 4,4 KB auf 7,0 KB über QUIC. Fast alles davon sitzt in den beiden Hello-Nachrichten, etwa 1,2 KB im ClientHello und 1,1 KB im ServerHello. QUIC-Handshakes sind in jeder Konfiguration etwa 1 KB grösser als TCP-Handshakes, mit PQC oder ohne. QUIC spart ein paar Bytes dank der leichteren UDP-Header, verliert aber mehr davon wieder, weil es die Initial-Pakete des Clients auf 1’200 Bytes padded, um DDoS-Amplification-Angriffe zu verhindern. Clients wenden ausserdem GREASE an und randomisieren den ClientHello, damit «Middleboxes» keine festen Bytes annehmen, sodass die genauen Grössen von Verbindung zu Verbindung leicht variieren.
Wenn nur eine Seite PQC unterstützt, ist der Aufwand nicht symmetrisch. Ein Client, der einem klassischen Server PQC anbietet, schickt seinen 1,2-KB-Key-Share trotzdem, umsonst, während ein Server mit aktiviertem PQC für klassische Clients kein einziges Byte zusätzlich sendet. Die meisten Ihrer Besucherinnen und Besucher zahlen diese Maut bereits bei jeder Verbindung und bekommen dafür keinen Schutz. PQC auf dem Server zu aktivieren kostet klassische Clients nichts und macht aus den Bytes, die sie ohnehin schon senden, echten Schutz.
Stellen Sie diese Kilobytes neben den Rest der Verbindung. Wir haben einen Nachmittag normales Browsing aufgezeichnet und den Gesamttraffic durch die Anzahl Handshakes geteilt. Unser Nachmittag Browsing ergab rund 70 KB pro Handshake im Durchschnitt. Der Post-Quantum-«Overhead» macht also weniger als 4% des Traffics aus.
Handshake-Zeit
TLS-Handshake-Zeit auf sauberer Verbindung
Auf einer sauberen Verbindung ist der quantensichere Schlüsselaustausch fast gratis. Voller PQC kostet 0,4 ms mehr über TCP und 0,9 ms mehr über QUIC, weniger als die Streuung von etwa 1,5 ms zwischen Läufen. Wenn nur eine Seite die hybride Gruppe unterstützt, einigen sich die beiden auf X25519, und der Handshake kostet dasselbe wie vorher. Die CPU-Zeit bewegt sich ebenfalls nicht, auf Client oder Server. ML-KEM läuft in Dutzenden von Mikrosekunden, etwa so schnell wie X25519. Der echte Unterschied liegt zwischen den Transports. QUIC schafft es in etwa 23 ms gegen 44 ms für TCP, weil es den Transport- und den TLS-Handshake zusammen abwickelt und ein volles «Round Trip» spart. TCP muss seinen eigenen Handshake abschliessen, bevor TLS überhaupt anfangen kann.
TLS-Handshake-Zeit auf degradiertem Wi-Fi
Der Unterschied fällt auf einem schlechten Netzwerk stärker ins Gewicht. Wir haben dieselben Läufe über eine simulierte degradierte Wi-Fi-Verbindung wiederholt, was jeden Handshake ungefähr verdoppelt. Voller PQC kostet jetzt 6,4 ms mehr über TCP (+8%) und 7,0 ms mehr über QUIC (+16%). Der Aufwand kommt von Paketen, nicht von Rechenleistung. Die grösseren Hellos treiben einen TCP-Handshake von 10 auf 14 Pakete und einen QUIC-Handshake von 6 auf etwa 9. Jedes zusätzliche Paket gibt «Delay» und «Loss» eine weitere Chance, den Handshake aufzuhalten. Selbst ein PQC-Client gegenüber einem klassischen Server verliert 4,3 ms über QUIC, weil sein grösserer ClientHello das Netzwerk passiert, egal was der Server wählt.
Authentifizierung ist weiterhin klassisch
Der hybride Schlüsselaustausch schliesst die HNDL-Lücke. Er schützt keine Authentifizierung, die weiterhin auf klassischen Signaturen ruht, die ein Quantencomputer eines Tages fälschen kann. Der Unterschied ist das Timing. Ein aufgezeichneter Handshake lässt sich Jahre später entschlüsseln, während eine Signatur nur auf einer Verbindung im Echtbetrieb gefälscht werden kann. Deshalb war der Schlüsselaustausch zuerst dran.
Merkle Tree Certificates (MTCs) aus der IETF-PLANTS-Arbeitsgruppe nehmen sich der Grösse von Post-Quantum-Signaturen an. Google und Cloudflare beenden gerade ein Live-Experiment, das bewiesen hat, dass der Ansatz funktioniert, und die Produktion folgt als Nächstes. Let’s Encrypt plant, MTCs 2027 auszustellen, und Cloudflare startet seine eigene öffentliche CA, um dasselbe ab Anfang 2027 zu tun. MTCs und die Zukunft des Web PKI behandeln wir in einem eigenen Beitrag. Bis dahin ist der Schlüsselaustausch die Hälfte, die Sie kontrollieren.
