Post-Quantum-TLS heute: was ML-KEM und X25519-Hybrid praktisch leisten

5 Min Lesezeit Serie: infrastructure #tls#post-quantum#krypto#ml-kem

Harvest-now, decrypt-later ist kein akademisches Szenario. Warum Quantum-resistente Schlüsselaustausche heute in TLS 1.3 gehören, wie der Hybrid-Modus aussieht und was bei der Einführung schiefgehen kann.

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 gelten als effizient lösbar, sobald ein ausreichend grosser Quantencomputer existiert, Shors Algorithmus löst sie in polynomialer Zeit.

Ein solcher Quantencomputer existiert heute nicht. Der Angriff existiert aber dennoch, in einer zeitversetzten Variante: Harvest-now, decrypt-later. Ein Angreifer zeichnet 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.

Kurze Antwort

Die praktische Antwort 2024 ist ein hybrider Key Exchange in TLS 1.3: klassischer Curve X25519 kombiniert mit dem Post-Quantum-KEM Kyber-768 aus der finalen NIST-PQC-Auswahl; die FIPS-Fassung als ML-KEM wird im Laufe des Jahres erwartet. Der Hybrid sichert gegen beide Seiten ab: selbst wenn Kyber in den nächsten Jahren kryptanalytisch fallen sollte, bleibt die klassische Hälfte gegen heutige Rechenkraft sicher; umgekehrt schützt der Post-Quantum-Anteil bereits heute gegen zukünftige Quantenangriffe.

Chrome rollt den Hybrid seit Version 116 schrittweise aus, ab Version 124 standardmässig; BoringSSL und die Cloudflare-Edge fahren ihn bereits seit 2023, OQS-Patches der gängigen TLS-Stacks ebenfalls. Die Einführung auf dem eigenen Server ist eine Konfigurationszeile.

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 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 Lattice-basierten Verfahren wie ML-KEM 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 von Kyber-768 ist 1184 Bytes gross, der Ciphertext 1088 Bytes. Ein Hybrid-ClientHello enthält damit rund 1200 Bytes zusätzliche Payload im Vergleich zu reinem X25519 (32 Bytes). Das ist zweimal ein einzelnes TCP-Segment, in den meisten Netzen vernachlässigbar, auf hoch-latenten Mobilfunk-Strecken im einstelligen Millisekundenbereich 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. Gegenüber dem klassischen X25519 fällt das auf der Server-Seite kaum auf.

Deployment-Beispiel

nginx mit BoringSSL oder OQS-Patch:

# /etc/nginx/sites-available/example.conf
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:

# traefik.yml
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 BSI dazu sagt

Das BSI hat in TR-02102-2 (Kryptografische Verfahren: Verwendung von TLS, SSH und IPsec) Post-Quantum-Hybrid-Verfahren als empfohlene Schicht aufgenommen. Die Empfehlung ist ausdrücklich additiv: Hybrid bedeutet Hybrid, nicht Ersetzung. Reine PQ-Algorithmen ohne klassische Hälfte werden nicht empfohlen, solange die Lattice-Analyse noch im Fluss ist.

Was sich 2024 nicht ändert

Die Signaturen in TLS-Zertifikaten 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 (Sub-CAs, Intermediate-CAs, Roots) 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. Harvest-now-decrypt-later braucht nichts als Speicherplatz.

"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) 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 Harvest-now.

Wie Svelnor hier hilft

Post-Quantum-TLS ist bei Svelnor Infrastruktur-Baseline, nicht eigenes Produkt. Der Traefik-Ingress vor saemtlichen Svelnor-Diensten (Auth, Clean, Note, Scan und weitere) terminiert TLS 1.3 mit dem beschriebenen Hybrid-Key-Exchange auf Basis BoringSSL plus OQS-Patches. Kunden, die ihre eigene Infrastruktur prüfen lassen wollen, koennen die hier verlinkten Testwerkzeuge (SSL Labs, openssl s_client -groups ...) gegen ihre Domains laufen lassen; das Ergebnis ist die einzige belastbare Aussage.

Verifikation

Offene Punkte

Signatur-Migration. Die klassische Zertifikats-PKI wird noch Jahre auf ECDSA/RSA-PSS bleiben. Der CA/Browser Forum wird die Migration steuern; mit Rollout ab 2026 ist zu rechnen, Vollumstellung 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össen (Kyber-512) sind hier das pragmatische Mittel.

CRYSTALS-Kyber vs. ML-KEM. Beide bezeichnen dasselbe Grundverfahren. ML-KEM wird die NIST-standardisierte, geringfügig angepasste Variante sein (Änderungen bei Domain-Separation-Konstanten erwartet); Bibliotheken und Browser nutzen derzeit den Kyber-Round-3-Stand, der Umstieg auf ML-KEM steht nach Finalisierung der FIPS-Fassung an.

Aktualisierungen