Post-Quantum-TLS heute: ML-KEM und X25519-Hybrid

Problem

Die Sicherheit klassischer TLS-Schlüsselaustausche (RSA-Key-Transport, ECDHE über X25519 oder P-256) beruht auf dem Faktorisierungs- beziehungsweise dem diskreten-Logarithmus-Problem. Beide Probleme galten lange als "schwierig zu lösende" Probleme, man verließ sich darauf, dass es sich für niemanden praktisch lösen ließ. Aber genau diese Probleme gelten mittlerweile als effizient lösbar, sobald ein ausreichend großer Quantencomputer existiert, Shors Algorithmus löst sie in endlicher (polynomialer) Zeit.

Ein solcher Quantencomputer existiert unseres Wissens nach heute nicht - zumindest ist dies nicht öffentlich bekannt. Der Angriff existiert aber dennoch, in einer zeitversetzten Variante: Harvest-/Store-now, decrypt-later ist real. Ein Angreifer zeichnet hierbei verschlüsselten Datenverkehr heute auf, speichert ihn und entschlüsselt ihn in zehn bis zwanzig Jahren. Für Daten mit langer Vertraulichkeits-Halbwertszeit (Patientenakten, Rechtskommunikation, Konstruktionsunterlagen, Ausschreibungen) ist das bereits jetzt ein konkretes Problem. Staatliche Akteure verfügen bereits seit langem sowohl über den Zugang zu entsprechenden Internetknoten (wo die Daten abgegriffen werden können) als auch über die nötigen finanziellen Mittel (Kauf und Betrieb von Millionen Festplatten).

Für wen ist das? Für Administratoren und Architekten, die TLS gegen künftige Quantenangriffe wappnen wollen.

Tiefgang

Was hybrid bedeutet

Im TLS-1.3-Handshake werden Schlüsselaustauschverfahren durch sogenannte Named Groups identifiziert. Ein klassisches X25519 hat den Code Point 0x001D. Der aktuell ausgerollte Hybrid heißt X25519Kyber768Draft00 und trägt den Code Point 0x6399; nach Abschluss der FIPS-Standardisierung wird eine umbenannte Variante (X25519MLKEM768) mit eigenem Code Point folgen, die eigentliche Mechanik bleibt gleich. Client und Server handeln den Namen wie bei jedem anderen Key-Exchange aus; im Hintergrund laufen beide Verfahren parallel, und die resultierenden Shared Secrets werden per HKDF (HMAC-based Key Derivation Function, ein standardisiertes Verfahren zum Ableiten von Schlüsseln) zu einem einzigen abgeleiteten Handshake-Secret zusammengehasht.

Der Zweck der Kombination: Solange mindestens eines der beiden Basis-Verfahren sicher ist, ist der Hybrid sicher. Das entkoppelt die Verfügbarkeit des Quantenschutzes von der Gewissheit, dass ML-KEM wirklich so unangreifbar ist, wie die aktuelle Analyse andeutet. Bei Gitter-basierten Verfahren wie ML-KEM (deren Sicherheit auf der Schwierigkeit bestimmter Aufgaben in mathematischen Gittern beruht) sind die Sicherheitsargumente jünger als bei RSA oder ECDH; der Hybrid versichert gegen das Risiko einer unbekannten Schwäche.

Kosten im Handshake

Der Pubkey (öffentliche Schlüssel) von Kyber-768 ist 1184 Bytes groß, der Ciphertext (verschlüsselter Schlüsseltransport) 1088 Bytes. Ein Hybrid-ClientHello (die erste Nachricht des Clients im Handshake) enthält damit rund 1 KB zusätzliche Payload im Vergleich zu reinem X25519 (32 Bytes). Das ist zweimal ein einzelnes TCP-Segment, in den meisten Netzen vernachlässigbar und selbst auf hoch-latenten Mobilfunk-Strecken im einstelligen Millisekundenbereich ebenfalls nicht fühlbar.

Der CPU-Aufwand für die Operationen selbst ist klein: Kyber-768 liegt auf modernen x86-Kernen unter 100 Mikrosekunden pro Keygen und unter 50 Mikrosekunden pro Encap/Decap (Schlüssel-Einkapselung beziehungsweise -Entkapselung). Gegenüber dem klassischen X25519 fällt das auf der Server-Seite kaum auf.

Deployment-Beispiel

nginx mit BoringSSL oder OQS-Patch (Open Quantum Safe, eine Bibliothek mit Post-Quantum-Verfahren):

server {
 listen 443 ssl;
 ssl_protocols TLSv1.3;
 ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
 ssl_ecdh_curve X25519Kyber768Draft00:X25519:P-256;
}

Traefik:

tls:
 options:
 default:
 minVersion: VersionTLS13
 curvePreferences:
 - X25519Kyber768Draft00
 - X25519

Beide Server bieten dem Client beim ClientHello eine priorisierte Liste an. Ein moderner Client wählt X25519Kyber768Draft00, ein älterer fällt auf X25519 zurück.

Was das BSI dazu sagt

Das BSI hat in TR-02102-2 (BSI = Bundesamt für Sicherheit in der Informationstechnik; die TR-02102-2 behandelt kryptografische Verfahren für TLS, SSH und IPsec) Post-Quantum-Hybrid-Verfahren als empfohlene Schicht aufgenommen. Die Empfehlung ist ausdrücklich additiv, also "hybrid". Reine PQ-Algorithmen ohne klassische Hälfte werden nicht empfohlen, solange der mathematische Hintergrund noch nicht gefestigt ist.

Was sich 2024 nicht ändert

Die Signaturen in TLS-Zertifikaten (die kryptografischen Echtheits-Nachweise) bleiben in absehbarer Zeit klassisch (ECDSA mit P-256 oder P-384, RSA-PSS). Signatur-Migrationen auf Post-Quantum-Verfahren (ML-DSA, früher Dilithium; SLH-DSA, früher SPHINCS+; Falcon) stehen an, aber die Zertifikats-PKI (Public Key Infrastructure, die Kette aus Sub-CAs, Intermediate-CAs und Roots, die Zertifikate ausstellt und beglaubigt) ist deutlich schwerer zu migrieren als ein Key Exchange. Eine frühzeitig kompromittierte Signatur-Kette würde erst dann Auswirkungen haben, wenn ein Angreifer ein Zertifikat rückwirkend fälschen will, das ist eine bedeutend schwerere Messlatte als passive Entschlüsselung aufgezeichneten Verkehrs.

Deshalb ist die Reihenfolge: Key Exchange zuerst, Signaturen später. Wer heute Key Exchange abdeckt, ist für Harvest-now-Risiken geschützt.

Abgelehnte Alternativen und Mythen

"Reines Kyber ohne Hybrid." Für Produktivsysteme zu früh. Der kryptografische Stand von Lattice-basierten Verfahren ist jünger als das der klassischen ECC-Verfahren; eine unbekannte Schwäche würde den gesamten Kanal aufbrechen.

"Wir warten, bis Post-Quantum fertig ist." Das Warten ist der Angriff. Store-now-decrypt-later ist bewusst langfristig ausgelegt.

"SIKE, NTRU, SABER." SIKE wurde 2022 durch einen klassischen Angriff gebrochen und aus dem NIST-Verfahren entfernt. NTRU und SABER sind aus Round 2 nicht in die finale Standardisierung gekommen. Wer heute Post-Quantum ausrollt, nimmt die NIST-Finalisten: Kyber für Key Exchange, Dilithium für Signaturen, SPHINCS+ für hash-basierte Signaturen, nach FIPS-Finalisierung tragen sie die Namen ML-KEM, ML-DSA, SLH-DSA.

"Wir haben Forward Secrecy, das reicht." Forward Secrecy (ephemeral DH; jeder Sitzung wird ein flüchtiger Schlüssel zugewiesen, sodass ein später kompromittierter Langzeit-Schlüssel alte Sitzungen nicht aufdeckt) schützt, solange der ephemerale DH-Schlüssel nicht entschlüsselbar ist. Genau das wird durch Shors-Algorithmus an einem Quantencomputer aufgebrochen. Forward Secrecy ohne PQ-Anteil leistet nichts gegen Store-now-Decrypt-later.

Was Sie jetzt tun sollten

1. Prüfen Sie zuerst, ob Ihre Server-Software (nginx mit BoringSSL/OQS, Traefik, Caddy) den Hybrid X25519Kyber768Draft00 schon unterstützt - das entscheidet, ob eine Konfigurationszeile reicht oder ein Update ansteht.
2. Aktivieren Sie den Hybrid mit Vorrang vor reinem X25519, sodass moderne Clients ihn wählen und ältere sauber zurückfallen.
3. Verifizieren Sie das Ergebnis von außen mit openssl s_client -groups X25519Kyber768Draft00 ... (siehe "Verifikation") oder den SSL Labs.
4. Setzen Sie Daten mit langer Vertraulichkeits-Halbwertszeit (Patienten-, Rechts-, Konstruktions-Daten) bei der Umstellung nach vorn - dort wirkt der Schutz am stärksten.
5. Planen Sie die Signatur-Migration (ML-DSA und Folge) als zweiten Schritt ein, aber priorisieren Sie zuerst den Schlüsselaustausch.

Verifikation

• FIPS 203 (ML-KEM): nist.gov/publications/FIPS-203.
• IETF TLS Hybrid Key Exchange Design: draft-ietf-tls-hybrid-design.
• BSI TR-02102-2: bsi.bund.de/TR-02102.
• Testen mit openssl: openssl s_client -connect example.com:443 -groups X25519Kyber768Draft00 -trace.
• SSL Labs: ssllabs.com/ssltest zeigt Hybrid-Support im Testergebnis.

Offene Punkte

Signatur-Migration. Die klassische Zertifikats-PKI wird noch Jahre auf ECDSA/RSA-PSS bleiben. Das CA/Browser Forum wird die Migration steuern; mit Rollout ab 2026 ist zu rechnen, die tatsächliche Umstellung eher im Lauf des Jahrzehnts.

Embedded-Systeme. Geräte mit kleinem Speicher (IoT, Smartcards ohne PQ-Unterstützung) können Kyber-768 nicht ohne Weiteres ausführen. Hybrid-Ausweichpfade und Verfahren mit kleineren Key-Größen (Kyber-512) sind hier das pragmatische Mittel.

CRYSTALS-Kyber vs. ML-KEM. Beide bezeichnen dasselbe Grundverfahren. ML-KEM ist die NIST-standardisierte, geringfügig angepasste Variante; Bibliotheken und Browser nutzen teils noch den Kyber-Round-3-Stand, der Umstieg auf ML-KEM läuft seit Finalisierung der FIPS-Fassung.

Häufige Fragen

Muss ich jetzt schon umstellen, wenn es noch keinen Quantencomputer gibt?

Ja, für sensible Daten. Der relevante Angriff ist nicht der heutige Entschlüsselungs-Versuch, sondern "store now, decrypt later": Datenverkehr wird heute aufgezeichnet und später entschlüsselt, sobald ein leistungsfähiger Quantencomputer existiert. Alles, was in zehn oder zwanzig Jahren noch vertraulich sein soll, profitiert daher schon jetzt vom hybriden Schlüsselaustausch.

Was bedeutet "hybrid" genau?

Hybrid heißt, dass im selben TLS-Handshake zwei Schlüsselaustausch-Verfahren parallel laufen - ein klassisches (X25519) und ein Post-Quantum-Verfahren (Kyber-768) - und ihre Ergebnisse zu einem gemeinsamen Schlüssel zusammengeführt werden. Der Kanal ist genau dann sicher, wenn mindestens eines der beiden Verfahren sicher ist. So ist man gegen eine Schwäche in jedem der beiden Bausteine abgesichert.

Bremst der Hybrid meine Server oder Verbindungen aus?

Praktisch nicht. Der zusätzliche Datenanteil im Handshake liegt bei rund 1 KB, das entspricht etwa zwei zusätzlichen Netzwerkpaketen und ist in den meisten Netzen nicht spürbar. Der Rechenaufwand für Kyber-768 liegt im Mikrosekundenbereich und fällt neben dem ohnehin nötigen TLS-Aufwand kaum ins Gewicht.

Warum nicht gleich reines Post-Quantum ohne klassischen Anteil?

Weil die Sicherheitsanalyse der Gitter-basierten Verfahren wie ML-KEM jünger ist als die jahrzehntelang untersuchte klassische Kryptografie. Sollte später eine unbekannte Schwäche auftauchen, würde ein reines Post-Quantum-Verfahren den ganzen Kanal öffnen. Der Hybrid behält die klassische Hälfte als Rückfallnetz und wird auch vom BSI in dieser Form empfohlen.

Schützt der Hybrid auch meine Zertifikate?

Nein. Der hybride Schlüsselaustausch schützt die Vertraulichkeit des Datenverkehrs. Die Echtheits-Nachweise der Zertifikate (die Signaturen) bleiben vorerst klassisch. Das ist vertretbar, weil deren Angriff einen Quantencomputer im Moment der Verbindung voraussetzt, während die Entschlüsselung aufgezeichneten Verkehrs jederzeit nachträglich möglich wäre. Die Signatur-Migration folgt als zweiter Schritt.