X25519MLKEM768 vs. X25519: Post-Quanten-TLS

Bei X25519MLKEM768 vs. X25519 geht es um die Wahl des Schlüsselaustauschs, die heute in jedem Handshake von TLS 1.3 fällt. X25519 allein ist schnell und sehr kompakt, fällt aber einem Quantencomputer zum Opfer – heute aufgezeichneter Datenverkehr könnte also später entschlüsselt werden. X25519MLKEM768 führt X25519 und ML-KEM-768 gemeinsam aus, sodass die Sitzung vertraulich bleibt, solange nicht beide gebrochen sind.

Auf einen Blick

Durchsatz mit openssl speed auf einem Kern eines Apple M4 Max gemessen; Handshake-Größen aus dem Mitschnitt unten.

Warum jetzt hybrid

Der Schlüsselaustausch ist anfällig für harvest now, decrypt later („jetzt speichern, später entschlüsseln“): Ein Angreifer zeichnet heute verschlüsselte Sitzungen auf und entschlüsselt sie, sobald es einen kryptografisch relevanten Quantencomputer gibt, indem er die Sitzungsschlüssel aus dem aufgezeichneten Austausch über X25519 zurückgewinnt. Forward Secrecy hilft dabei nicht, denn jeder aufgezeichnete Austausch lässt sich einzeln brechen. Alles, dessen Vertraulichkeit über das Erscheinen eines solchen Computers hinaus bestehen muss, ist schon heute gefährdet – deshalb kam der Schlüsselaustausch zuerst an die Reihe, während Signaturen länger warten können.

Die hybride Konstruktion sichert auch in die andere Richtung ab. ML-KEM wurde im August 2024 standardisiert und ist im Vergleich zu X25519 jung, ein Bruch – mathematisch oder in einer Implementierung – ist also nicht undenkbar. X25519MLKEM768 speist beide gemeinsamen Geheimnisse verkettet in den Key Schedule von TLS ein, sodass ein Angreifer beide brechen muss. RFC 10024 stellt bei dieser Gruppe den Key Share und das Geheimnis von ML-KEM an den Anfang – anders als bei den Hybriden mit NIST-Kurven (SecP256r1MLKEM768, 0x11EB, und SecP384r1MLKEM1024, 0x11ED), die ECDH voranstellen.

Was sich auf der Leitung ändert

Der Client sendet einen Key Share von 1.216 Byte statt 32 Byte, sodass ein typisches ClientHello von etwa 300 Byte auf etwa 1,5 KB wächst und mit all den anderen Extensions eines Browsers nicht mehr in ein einziges Netzwerkpaket passt. Der Server antwortet mit einem Key Share von 1.120 Byte. Ein echter Handshake mit Cloudflare, mitgeschnitten mit OpenSSL 3.6.5, zeigt den Unterschied:

echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519MLKEM768 -brief 2>&1 | grep -E "Protocol|group"
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519MLKEM768 -msg 2>&1 | grep -E "ClientHello|ServerHello"
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519 -msg 2>&1 | grep -E "ClientHello|ServerHello"

Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
>>> TLS 1.3, Handshake [length 05cc], ClientHello
<<< TLS 1.3, Handshake [length 04ba], ServerHello
>>> TLS 1.3, Handshake [length 0132], ClientHello
<<< TLS 1.3, Handshake [length 007a], ServerHello

Das sind 1.484 gegenüber 306 Byte beim ClientHello und 1.210 gegenüber 122 beim ServerHello. Größere ClientHellos haben Fehler in Servern und Middleboxes offengelegt, die davon ausgingen, dass die Nachricht mit einem einzigen TCP-Lesevorgang oder in einem einzigen Paket ankommt; als Chrome in Version 124 (2024) hybride Key Shares mit Kyber standardmäßig aktivierte, mussten mehrere Firewall- und Proxy-Produkte korrigiert werden – eine Fehlerklasse, die tldr.fail dokumentiert. Cloudflare und Google meldeten, dass die zusätzlichen Bytes die mediane Handshake-Latenz um einige Prozent erhöhen; das fällt weit weniger ins Gewicht als die Roundtrips, die TLS 1.3 selbst einspart.

Stand der Verbreitung

• Browser: Chrome und Edge bieten X25519MLKEM768 seit Version 131 (November 2024) standardmäßig an, Firefox auf dem Desktop seit 132, Safari und das System-TLS von Apple seit iOS 26 und macOS 26 (2025). Das vorstandardisierte X25519Kyber768Draft00 (0x6399), das sie zuvor verwendeten, gilt als veraltet.
• Bibliotheken: OpenSSL 3.5 (April 2025) sendet standardmäßig Key Shares für X25519MLKEM768 und X25519; Go 1.24 aktiviert es in crypto/tls standardmäßig; JDK 27 (September 2026, JEP 527) bietet es standardmäßig an erster Stelle an; BoringSSL, rustls und NSS unterstützen es.
• Server und CDNs: Cloudflare, Google und andere große Anbieter handeln es mit Clients aus, die es unterstützen; nginx, Apache und HAProxy übernehmen es aus dem gelinkten OpenSSL.
• SSH: Das Gegenstück mlkem768x25519-sha256 ist seit OpenSSH 10.0 der Standard (RFC 10042).

Der Post-Quanten-Browser-Check zeigt, was dein eigener Browser aushandelt.

Wann welches Verfahren passt

• Öffentliches HTTPS und APIs: X25519MLKEM768 an erster und X25519 an zweiter Stelle anbieten; jeder moderne Client handelt das Hybridverfahren aus, alte fallen auf X25519 zurück.
• Internes Service Mesh und mTLS: standardmäßig hybrid, besonders für Daten, deren Vertraulichkeit lange gewahrt bleiben muss.
• Umgebungen mit FIPS-Vorgaben: SecP256r1MLKEM768 oder SecP384r1MLKEM1024, wenn die Liste zugelassener Verfahren deines Moduls NIST-Kurven verlangt; X25519MLKEM768 kommt infrage, wo ML-KEM die zugelassene Komponente ist.
• Eingeschränkte Verbindungen, bei denen jedes Paket zählt: zuerst messen; das Hybridverfahren fügt pro Richtung ein Paket hinzu, was meist vertretbar ist.
• X25519 allein: nur für Gegenstellen, die das Hybridverfahren nicht beherrschen, nie als bewusste Wahl für neue Installationen.

Hinweise zur Migration

1. Aktualisiere die TLS-Bibliothek (OpenSSL 3.5 oder neuer, Go 1.24 oder neuer, aktuelles BoringSSL oder rustls); mit OpenSSL 3.5 enthalten die Standardgruppen das Hybridverfahren bereits.
2. Wenn du Gruppen explizit setzt, füge das Hybridverfahren hinzu: zum Beispiel ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; in nginx oder Groups = X25519MLKEM768:X25519:P-256 in einer OpenSSL-Konfigurationsdatei.
3. Teste den ganzen Pfad, nicht nur den Server: Load Balancer, WAFs und Proxys mit TLS-Inspektion müssen ein ClientHello verarbeiten, das auf mehrere Pakete und Lesevorgänge verteilt ist; teste nach deren Updates erneut.
4. Prüfe, was ausgehandelt wird, mit openssl s_client -groups X25519MLKEM768 oder den Entwicklertools des Browsers, und überwache den Anteil hybrider Handshakes.
5. Plane die Signaturseite separat: Das Hybridverfahren schützt nur die Vertraulichkeit; Zertifikate und Handshake-Signaturen bleiben klassisch, bis Post-Quanten-Signaturen in der WebPKI ankommen.

Quellen

• RFC 10024, hybride PQ/T-Mechanismen zur Schlüsseleinigung für TLS 1.3
• RFC 9954, hybrider Schlüsselaustausch in TLS 1.3
• FIPS 203, ML-KEM
• RFC 7748, X25519
• IANA-Registry der TLS Supported Groups
• Release Notes zu OpenSSL 3.5
• tldr.fail: Fehler bei fragmentierten ClientHellos
• NIST IR 8547 ipd §4.1.2 (Schlüsseletablierung)