Post-Quantum-TLS ist HTTPS, das selbst gegen einen Angreifer mit einem großen Quantencomputer sicher bleibt. Es ersetzt die Mathematik hinter dem heutigen Schlüsselaustausch — die ein Quantencomputer brechen könnte — durch Algorithmen, die so konzipiert sind, dass sie Quantenangriffen standhalten.
Das ist kein fernes Forschungsprojekt. Mitte 2026 sind bereits über 65 % des menschlichen Web-Traffics über Cloudflare post-quantum-verschlüsselt, und Chrome, Edge und Firefox handeln standardmäßig einen quantensicheren Schlüsselaustausch aus, sobald der Server ihn unterstützt. Wenn Sie kürzlich mit einem modernen Browser Google besucht haben, haben Sie mit ziemlicher Sicherheit Post-Quantum-TLS genutzt, ohne es zu bemerken.
Warum klassisches TLS gefährdet ist
Heutiges TLS beruht auf zwei Arten von Public-Key-Mathematik:
- Schlüsselaustausch (ECDHE, mit X25519 oder P-256) — einigt sich über einen offenen Kanal auf ein gemeinsames Geheimnis.
- Signaturen (RSA, ECDSA) — weist nach, dass das Zertifikat authentisch ist.
Beide hängen von Problemen ab, die für klassische Computer schwer sind — die Faktorisierung großer Zahlen (RSA) und der diskrete Logarithmus auf elliptischen Kurven (ECC). Shors Algorithmus, ausgeführt auf einem ausreichend großen Quantencomputer, löst beide effizient. Ein „kryptografisch relevanter Quantencomputer“ (CRQC) existiert noch nicht, aber das Feld bewegt sich schnell genug, dass sich die Planung von „ob“ zu „wann“ verschoben hat.
Public-Key-Kryptografie → erklärt die zugrunde liegende Mathematik, die Quantencomputer bedrohen.
„Harvest now, decrypt later“ — warum das schon heute dringend ist
Sie könnten denken, es habe keine Eile: Kein Quantencomputer kann TLS heute brechen — warum also jetzt umsteigen?
Die Bedrohung lautet harvest now, decrypt later (HNDL) — also „jetzt ernten, später entschlüsseln“. Ein Angreifer zeichnet Ihren verschlüsselten Traffic heute auf und speichert ihn. Sobald ein Quantencomputer verfügbar wird — möglicherweise in den 2030er-Jahren — entschlüsselt er den gespeicherten Traffic rückwirkend.
Dadurch liegt die Frist für den Schlüsselaustausch deutlich vor dem Eintreffen von Quantencomputern. Alle Daten mit einer langen Vertraulichkeitsdauer — Gesundheitsdaten, Finanzdaten, Staatsgeheimnisse, Quellcode, Zugangsdaten — benötigen jetzt quantensichere Verschlüsselung, denn die Aufzeichnung findet bereits statt.
Der Schlüsselaustausch ist dringend. Signaturen sind es weniger. Sie können eine Signatur auf bereits erfolgtem Traffic nicht rückwirkend fälschen — eine Signatur muss nur bevor Quantencomputer existieren quantensicher sein, nicht früher. Deshalb hat die Branche den Post-Quantum-Schlüsselaustausch zuerst ausgerollt.
Die Standards: ML-KEM und ML-DSA
Im August 2024 veröffentlichte NIST die ersten finalisierten Post-Quantum-Standards:
| Standard | Name | Rolle | Ersetzt |
|---|---|---|---|
| FIPS 203 | ML-KEM (früher Kyber) | Schlüsselkapselung (Schlüsselaustausch) | ECDHE- / RSA-Schlüsselaustausch |
| FIPS 204 | ML-DSA (früher Dilithium) | Digitale Signaturen | RSA- / ECDSA-Signaturen |
| FIPS 205 | SLH-DSA (SPHINCS+) | Hash-basierte Signaturen | Konservatives Signatur-Backup |
ML-KEM (Module-Lattice Key Encapsulation Mechanism) ist der Mechanismus, der bereits in TLS ausgerollt ist. Er kommt in drei Größen: ML-KEM-512, ML-KEM-768 und ML-KEM-1024. ML-KEM-768 ist der ideale Mittelweg, der im Web verwendet wird.
Hybrider Schlüsselaustausch: X25519MLKEM768
Browser verwerfen die klassische Kryptografie nicht über Nacht und stellen auf reines Post-Quantum um. Das wäre leichtsinnig — ML-KEM ist neu, und ein Fehler könnte alles brechen. Stattdessen verwendet TLS 1.3 einen hybriden Schlüsselaustausch, der einen klassischen und einen Post-Quantum-Algorithmus kombiniert.
Die benannte Gruppe, die Ihnen 2026 begegnet, ist X25519MLKEM768:
X25519MLKEM768 = X25519 (classical ECDHE) + ML-KEM-768 (post-quantum)Die beiden gemeinsamen Geheimnisse werden aneinandergehängt (32 bytes aus X25519 + 32 bytes aus ML-KEM = ein kombiniertes Geheimnis von 64 bytes) und in den TLS-Schlüsselplan (Key Schedule) eingespeist.
Die Sicherheitsgarantie lautet „sicher, solange eines von beiden hält“. Ein Angreifer muss sowohl X25519 als auch ML-KEM-768 brechen, um den Sitzungsschlüssel wiederherzustellen. Also:
- Sollte sich herausstellen, dass ML-KEM-768 einen Fehler hat → schützt X25519 Sie weiterhin (gegen klassische Angreifer).
- Sollte ein Quantencomputer X25519 brechen → schützt ML-KEM-768 Sie weiterhin.
Dieses doppelt abgesicherte Design ist der Grund, warum Hybrid überall der Standard ist und nicht reines Post-Quantum.
Wo es im Handshake eingefügt wird
Der hybride Schlüsselaustausch verwendet denselben TLS-1.3-Handshake, der unter Was ist TLS 1.3 → beschrieben wird. Der einzige Unterschied ist der key_share: Das ClientHello trägt einen X25519MLKEM768-Key-Share statt eines einfachen X25519-Key-Shares. ML-KEM-Schlüssel sind größer (~1.2 KB gegenüber 32 bytes), sodass das ClientHello um etwa ein Kilobyte wächst — meist vernachlässigbar, kann jedoch in eingeschränkten Netzwerken gelegentlich über Paketgrenzen hinaus reichen.
Es bietet Ihnen außerdem weiterhin Forward Secrecy →: ein frisches Schlüsselpaar pro Verbindung, in der Post-Quantum-Edition.
Was 2026 bereits ausgerollt ist
| Komponente | Post-Quantum-Status (Mitte 2026) |
|---|---|
| Chrome / Edge | X25519MLKEM768 standardmäßig ausgehandelt |
| Firefox | X25519MLKEM768 unterstützt und aktiviert |
| Cloudflare | 65 %+ des menschlichen Traffics PQ-verschlüsselt; Schlüsselaustausch abgeschlossen |
| Liefert Post-Quantum-Schlüsselaustausch aus | |
| AWS | ML-KEM in KMS, ACM, Secrets Manager; legacy Kyber wird 2026 abgekündigt |
| OpenSSL 3.5+ | Native Unterstützung für ML-KEM und X25519MLKEM768 |
| Java (SunJSSE) | X25519MLKEM768 standardmäßig aktiviert |
Der Baustein, der noch nicht im großen Maßstab umgesetzt ist, sind Post-Quantum-Zertifikate — also das Signieren von Zertifikaten mit ML-DSA statt RSA/ECDSA. ML-DSA-Signaturen und öffentliche Schlüssel sind weitaus größer (Kilobyte gegenüber ~64 bytes), was den Handshake aufbläht und die Größenbeschränkungen von Zertifikatsketten belastet. Cloudflare plant ML-DSA auf Origin-Verbindungen bis Mitte 2026 und erprobt Merkle Tree Certificates, um die Größe handhabbar zu halten, mit dem Ziel, bis 2029 vollständig post-quantum-fähig zu sein (einschließlich Authentifizierung).
So prüfen Sie, ob Sie Post-Quantum-TLS verwenden
Im Browser
Öffnen Sie eine beliebige große Website in Chrome → DevTools → Reiter Security → sehen Sie sich die Verbindungsdetails an. Eine Post-Quantum-Verbindung zeigt einen Schlüsselaustausch wie X25519MLKEM768 (oder X25519Kyber768 bei älteren Builds).
Mit OpenSSL 3.5+
openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null | grep -i "Negotiated TLS1.3 group"
# Erwartet: Negotiated TLS1.3 group: X25519MLKEM768Wenn Sie einen Fehler oder eine andere Gruppe erhalten, ist entweder Ihr OpenSSL älter als 3.5, oder der Server bietet noch keinen Post-Quantum-Schlüsselaustausch an.
Prüfen Sie Ihre OpenSSL-Version
openssl version
# Benötigt: OpenSSL 3.5+ für natives X25519MLKEM768So aktivieren Sie es auf Ihrem Server
Für die meisten Websites lautet die Antwort aktualisieren und nicht deaktivieren — der hybride Post-Quantum-Schlüsselaustausch wird automatisch aktiviert, sobald Ihr Stack ihn unterstützt.
Nginx / Apache
Der Post-Quantum-Schlüsselaustausch lebt in Ihrer TLS-Bibliothek, nicht in der Webserver-Konfiguration. Bauen oder betreiben Sie Ihren Server gegen OpenSSL 3.5+ (oder BoringSSL mit ML-KEM). Sobald die Bibliothek eingebunden ist, wird X25519MLKEM768 automatisch neben X25519 angeboten — keine neue Direktive erforderlich. Pinnen Sie ssl_ecdh_curve nicht auf eine einzelne klassische Kurve, sonst schließen Sie die Hybrid-Gruppe aus.
Hinter einem CDN
Der einfachste Weg: Stellen Sie Ihre Website hinter Cloudflare (oder ein anderes PQC-fähiges CDN). Die Verbindung vom Browser zum Edge wird sofort post-quantum-fähig, ohne Änderungen an Ihrem Origin. Auf diese Weise wurde der Großteil jener 65 % des Traffics quantensicher — die Betreiber haben ihre Origin-Server überhaupt nicht angefasst.
Ihr Zertifikat ändert sich noch nicht
Sie benötigen für den Post-Quantum-Schlüsselaustausch kein neues Zertifikat. Ihr bestehendes RSA- oder ECC-Zertifikat funktioniert einwandfrei — der hybride Schlüsselaustausch schützt die Sitzung, während das Zertifikat vorerst weiterhin klassische Signaturen verwendet. Post-Quantum-Zertifikate (ML-DSA) sind eine separate, spätere Migration.
Häufig gestellte Fragen
Muss ich ein spezielles „quantensicheres Zertifikat“ kaufen?
Nein. Der Post-Quantum-Schlüsselaustausch (der dringende Teil) berührt Ihr Zertifikat überhaupt nicht — Ihr aktuelles RSA-/ECC-Zertifikat funktioniert weiterhin. Wer Ihnen heute ein „quantensicheres SSL-Zertifikat“ verkauft, betreibt größtenteils Marketing; produktive Post-Quantum-Signaturen (ML-DSA) werden von öffentlichen CAs noch nicht breit ausgestellt.
Ist Post-Quantum-TLS langsamer?
Kaum. ML-KEM-768 ist rechnerisch schnell — oft schneller als ECDHE. Die Hauptkosten liegen in der Größe: Die größeren Key-Shares fügen dem Handshake ~1 KB hinzu, was nur in Netzwerken mit sehr kleinen Paketgrenzen einen zusätzlichen Roundtrip kosten kann. Für nahezu alle Nutzer ist der Unterschied nicht messbar.
Wann werden Quantencomputer RSA tatsächlich brechen?
Niemand weiß es. Glaubwürdige Schätzungen reichen von den frühen 2030er-Jahren bis hin zu „vielleicht nie im großen Maßstab“. Aber wegen harvest now, decrypt later ist die Einsatzfrist für den Schlüsselaustausch bereits da — genau deshalb haben Browser und CDNs 2024–2026 gehandelt, statt zu warten.
Was ist mit TLS 1.2?
Der hybride Post-Quantum-Schlüsselaustausch ist nur für TLS 1.3 definiert. Das ist ein weiterer Grund, TLS 1.3 → zu aktivieren — es ist der einzige Weg zu quantensicherem HTTPS. TLS 1.2 wird keinen Post-Quantum-Schlüsselaustausch erhalten.
Ist ML-KEM dasselbe wie Kyber?
Ja — ML-KEM ist die von NIST standardisierte Version des Algorithmus, der früher CRYSTALS-Kyber hieß. Ältere Browser-Builds und Tools zeigen Kyber768; standardisierte Implementierungen verwenden ML-KEM-768. Sie sind eng verwandt, aber nicht Bit für Bit identisch, sodass ein Client mit dem finalen Standard und ein Server vor dem Standard die Aushandlung möglicherweise nicht abschließen. Bis 2026 ist das Ökosystem weitgehend auf das finale ML-KEM umgestiegen.
Sollte ich jetzt sofort etwas tun?
Für eine typische Website: Stellen Sie sicher, dass Sie auf TLS 1.3 sind, halten Sie Ihre TLS-Bibliothek aktuell (OpenSSL 3.5+), und ziehen Sie ein PQC-fähiges CDN in Betracht, wenn Sie langlebige sensible Daten verarbeiten. Das reicht aus, um heute einen quantensicheren Schlüsselaustausch zu erhalten. Post-Quantum-Zertifikate können warten, bis die Standards und das CA-Tooling ausgereift sind.