Jede HTTPS-Verbindung ruht auf zwei Bausteinen asymmetrischer Kryptografie: einem Schlüsselaustausch, der das Sitzungsgeheimnis ableitet, und einer digitalen Signatur, die belegt, dass der Server der ist, der er zu sein vorgibt. Beide sind (im Prinzip schon heute) durch Shors Algorithmus auf einem hinreichend großen Quantencomputer gebrochen. Die Migration zu Post-Quanten-HTTPS ist für den Schlüsselaustausch weit fortgeschritten und für die Authentifizierung kaum begonnen. Diese beiden Hälften folgen nicht derselben Uhr, und warum das so ist, ist die eigentliche Geschichte.
Was ein Quantenangreifer wirklich bricht
Der TLS-1.3-Handshake kombiniert einen ephemeren Schlüsselaustausch (typischerweise X25519, eine Variante von Diffie–Hellman auf elliptischen Kurven) mit einer Serversignatur über das Transkript (RSA, ECDSA oder Ed25519). Die Identität des Servers wird wiederum durch eine X.509-Zertifikatskette belegt, die selbst eine Folge von Signaturen ist, die in einem Wurzelzertifikat im Trust Store des Clients endet.
Shors Algorithmus faktorisiert ganze Zahlen in polynomialer Zeit, , und löst das diskrete Logarithmusproblem auf elliptischen Kurven mit derselben Asymptotik. Das zerstört RSA, DH, ECDH, ECDSA und Ed25519 gleichzeitig. Grovers Algorithmus liefert dagegen nur eine quadratische Beschleunigung gegen symmetrische Primitive, sodass AES-256 und SHA-384 komfortabel bleiben.
Das Bedrohungsmodell für HTTPS ist also schmal, aber total: die gesamte asymmetrische Schicht muss ersetzt werden, während die symmetrische Schicht bestehen bleiben kann.
Zwei Migrationen, nicht eine
Dies ist die wichtigste Sichtweise in der Post-Quanten-HTTPS-Diskussion, und sie kommt direkt von den Teams, die die Änderungen ausliefern. Chromes Kryptografieführung formuliert es so:
„Ein Angreifer könnte verschlüsselten Verkehr jetzt speichern, warten, bis ein CRQC praktikabel ist, und ihn dann nachträglich entschlüsseln.” — Adrian, Beck, Benjamin, O’Brien, Advancing Our Amazing Bet on Asymmetric Cryptography, Google, Mai 2024.
Dieser Angriff, harvest now, decrypt later, ist der Grund, warum die Migration des Schlüsselaustauschs nicht warten kann. Aufgezeichneter Verkehr von heute wird später entschlüsselbar; der Quantencomputer muss nur irgendwann existieren.
Authentifizierung hat die entgegengesetzte Eigenschaft. Eine gefälschte Signatur nützt nur, solange der Angreifer online ist. Solange kein kryptografisch relevanter Quantencomputer (CRQC) physisch existiert, fälscht niemand etwas. Wie Cloudflare es formuliert:
„Organisationen stehen vor zwei getrennten Post-Quanten-Migrationen: Schlüsselaustausch ist dringend; Signaturen sind weit komplexer, aber weniger zeitkritisch.” — Westerbaan, The State of the Post-Quantum Internet, Cloudflare, März 2024.
Die Branche liefert deshalb zuerst und aggressiv den Schlüsselaustausch aus und zweitens und vorsichtig die Authentifizierung.
Die neuen Bausteine
Das NIST hat im August 2024 drei Standards abgeschlossen. Ein vierter befindet sich im Entwurf.
| Standard | Algorithmus | Zweck | Zugrundeliegendes Problem |
|---|---|---|---|
| FIPS 203 | ML-KEM (Kyber) | Schlüsselkapselung | Module-LWE auf Gittern |
| FIPS 204 | ML-DSA (Dilithium) | Signaturen | Module-LWE / Module-SIS |
| FIPS 205 | SLH-DSA (SPHINCS+) | Signaturen (zustandsloses Hash-Verfahren) | Hashfunktionssicherheit |
| Entwurf | FN-DSA (Falcon) | Signaturen (kompakt) | NTRU-Gitter |
Im März 2025 hat das NIST zusätzlich HQC als codebasierten Ersatz-KEM ausgewählt, eine Absicherung gegen einen möglichen Bruch der Gitterannahmen.
Die relevanten Schlüssel- und Signaturgrößen sind die Quelle aller folgenden betrieblichen Probleme:
| Algorithmus | Öffentlicher Schlüssel | Signatur / Chiffretext |
|---|---|---|
| X25519 | 32 B | 32 B |
| Ed25519 | 32 B | 64 B |
| ECDSA P-256 | 64 B | ~70 B |
| RSA-2048 | 256 B | 256 B |
| ML-KEM-768 | 1.184 B | 1.088 B |
| ML-DSA-44 | 1.312 B | 2.420 B |
| SLH-DSA-128s | 32 B | 7.856 B |
| FN-DSA-512 | 897 B | 666 B |
Gitterbasierte KEMs sind brauchbar. Gitterbasierte Signaturen sind unhandlich. Hash-basierte Signaturen sind groß. Kompakte Signaturen (Falcon) erfordern Gleitkomma-Arithmetik beim Signieren, eine Klasse von Albtraumimplementierungen für konstantzeitige Ausführung.
Hybrider Schlüsselaustausch ist bereits Standard
Der TLS-Einsatz für den Schlüsselaustausch ist hybrid: eine klassische Kurve und ein Post-Quanten-KEM laufen parallel, und das Sitzungsgeheimnis wird aus beiden abgeleitet:
Hält eines der beiden Verfahren, hält die Sitzung. Der standardisierte Codepunkt ist X25519MLKEM768 (0x11EC in TLS) und ersetzt das frühere experimentelle X25519Kyber768Draft00 (0x6399); notwendig wurde der Wechsel, weil der endgültige ML-KEM-Standard mit dem Kyber-Entwurf, auf dem er beruht, nicht draht-kompatibel ist.
Die Verbreitungszahlen sind bemerkenswert. Laut Cloudflares Bericht 2025:
„Über die Hälfte des von Menschen initiierten Verkehrs mit Cloudflare ist durch Post-Quanten-Verschlüsselung gegen Harvest-Now/Decrypt-Later geschützt.” — Westerbaan, State of the Post-Quantum Internet in 2025, Cloudflare, Oktober 2025.
Chrome aktivierte den hybriden ML-KEM-Schlüsselaustausch standardmäßig in Version 124 auf Desktops und meldet eine Median-Latenzsteigerung von 4 % im Handshake, nicht null, aber klein genug für die Auslieferung. ML-KEM fügt rund 1,1–1,2 kB zum ClientHello und ServerHello hinzu. Das ist der einzige Preis für Immunität gegen Harvest-Now/Decrypt-Later, und er wird gezahlt.
Der schwierige Teil: Zertifikate
Während die Migration des Schlüsselaustauschs im Wesentlichen abgeschlossen ist, hat die Migration der Zertifikate in Produktion noch nicht einmal begonnen. Die Arithmetik erklärt warum.
Ein moderner TLS-Handshake enthält ein Leaf-Zertifikat, ein oder zwei Zwischenzertifikate, zwei Signed Certificate Timestamps (SCTs) für Certificate Transparency und eine Signatur über das Handshake-Transkript. Heute liegt die Kette median bei etwa 3,2 kB. Mit ML-DSA-44-Signaturen, naiv gerechnet:
- zwei SCTs und eine Leaf-Signatur allein fügen 7.260 Bytes Authentifizierungs-Overhead hinzu;
- eine vollständige hybride Kette (klassisch + Post-Quanten) treibt die Handshake-Größe über 15 kB.
Diese Zahl ist wichtig, weil es eine gut dokumentierte Performance-Klippe gibt:
„Einige Clients oder Middleboxes mögen Zertifikatketten von mehr als 10 kB nicht. Diese Schwelle zu überschreiten löst zusätzliche Roundtrips aus und verursacht 60 % + Verlangsamung.” — Cloudflare, PQ-TLS-Experiment 2021, wiederholt in State of the Post-Quantum Internet, 2024.
Das ist Protokoll-Ossifikation in konkreter Form. Das anfängliche Congestion Window von TCP, das Anti-Amplification-Limit von QUIC, die MTU-Annahmen von Middleboxes, ASN.1-Pufferlängen in alten Stacks; jede Schicht des Stacks hat informell die Annahme verinnerlicht, dass ein TLS-Handshake klein ist.
Der Ausweg: Merkle Tree Certificates
Die vielversprechendste strukturelle Antwort sind Merkle Tree Certificates (MTC), ein IETF-Entwurf eines gemeinsamen Teams von Google, Cloudflare, Apple und Geomys in der PLANTS-Arbeitsgruppe:
„ML-DSA-44 verwendet 1.312 Bytes je öffentlichem Schlüssel und 2.420 Bytes je Signatur. Zwei SCTs und eine Leaf-Signatur addieren 7.260 Bytes Authentifizierungs-Overhead. Merkle-Tree-Zertifikate sind deutlich kleiner als eine einzelne ML-DSA-44-Signatur und fast zehnmal kleiner als die drei Signaturen, die für Post-Quanten-SCTs nötig wären.” — Benjamin, O’Brien, Westerbaan, Valenta, Valsorda, draft-ietf-plants-merkle-tree-certs.
Die Idee kehrt die traditionelle Kette um. Statt dass jedes Leaf eine Signatur trägt, führt die CA ein anhängbares Protokoll, signiert periodisch eine Merkle-Wurzel über den aktuellen Inhalt und gibt jedem Teilnehmer einen Inklusionsbeweis, einen logarithmisch großen Authentifizierungspfad vom Leaf zur Wurzel.
Für eine CA, die Zertifikate ausstellt, beträgt der Beweis etwa Bytes, und die teure ML-DSA-Signatur existiert nur einmal an der Wurzel. Laut demselben Entwurf reduziert das die Authentifizierungslast auf unter 800 Bytes pro Verbindung, kleiner als heutige RSA-Ketten.
Die Kompromisse sind real: Clients müssen vorab verteilte Merkle-Wurzeln vorhalten, Zertifikate werden erst nutzbar, nachdem die nächste Landmarke signiert wurde (es gibt also eine Ausgabeverzögerung), und das System verlangt eine Log-Infrastruktur, die über Certificate Transparency hinausgeht. Doch MTC ist der einzige Vorschlag, der gleichzeitig Post-Quanten-Sicherheit, Certificate Transparency und vertretbare Drahtgröße erreicht.
Wo die Migration steht
| Bereich | Status (Mitte 2026) |
|---|---|
| Symmetrische Kryptografie (AES, SHA-2/3) | Keine Änderung nötig |
| TLS-Schlüsselaustausch (X25519MLKEM768) | Standard in Chrome, Firefox, Cloudflare-Edge; >50 % des menschlichen Cloudflare-Verkehrs |
| Origin-seitiger Schlüsselaustausch | ~3,7 % der Origins (2025) |
| TLS-Authentifizierung (PQ-Zertifikate) | In Entwurfsphase; erste Testzertifikate 2026–2027 erwartet |
| Migration der CA-Wurzeln | In öffentlicher PKI noch nicht begonnen |
| OCSP / Sperrung in der PQ-Welt | Offenes Problem |
| Middlebox- / Appliance-Kompatibilität | Nicht skaliert getestet |
Die regulatorische Uhr variiert: Die CNSA 2.0 der NSA verlangt Post-Quanten für US-nationale Sicherheitssysteme bis 2033; EU- und UK-Leitlinien zielen für sensible Sektoren auf 2030–2035. Keine dieser Fristen funktioniert ohne eine Jahre vorher ausgelieferte Zertifikatslösung.
Der stille Teil
Diese Migration ist nicht wegen der Mathematik schwer. ML-KEM und ML-DSA sind reife, peer-reviewte Primitive, und die Implementierungen liegen offen. Sie ist deshalb schwer, weil HTTPS eine sechzig-Schichten-Torte ist: ein TLS-Handshake berührt eine CA, ein CT-Log, einen OCSP-Responder, einen Browser-Trust-Store, einen Kernel-TCP-Stack, einen Load Balancer, ein HSM, eine MTU-fixierte Middlebox und einen ASN.1-Parser von 2003. Jede dieser Komponenten hat eine Meinung dazu, wie groß ein Zertifikat sein darf.
Die Algorithmen zu wechseln ist der einfache Teil. Die Torte umzudimensionieren, ohne sie fallen zu lassen, ist der schwere Teil.
„Kryptografie wird selten gebrochen; sie wird umgangen.” — Adi Shamir
Das, und nicht irgendeine Qubit-Zahl, entscheidet darüber, ob HTTPS den Übergang würdevoll übersteht.
Quellen
- Westerbaan, B. State of the Post-Quantum Internet in 2025. Cloudflare, Oktober 2025. blog.cloudflare.com/pq-2025
- Westerbaan, B. The State of the Post-Quantum Internet. Cloudflare, März 2024. blog.cloudflare.com/pq-2024
- Adrian, D.; Beck, B.; Benjamin, D.; O’Brien, D. Advancing Our Amazing Bet on Asymmetric Cryptography. Google / Chromium, Mai 2024. blog.google/chromium/advancing-our-amazing-bet-on-asymmetric
- Benjamin, D.; O’Brien, D.; Westerbaan, B.; Valenta, L.; Valsorda, F. Merkle Tree Certificates. IETF draft-ietf-plants-merkle-tree-certs. datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs
- NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. August 2024. csrc.nist.gov/pubs/fips/203/final
- NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. August 2024.
- NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard. August 2024.
- Cloudflare. Post-quantum cryptography (PQC) — SSL/TLS docs. developers.cloudflare.com/ssl/post-quantum-cryptography