X25519MLKEM768: hybrider Schlüsselaustausch in TLS 1.3

Kurz gesagt. X25519MLKEM768 ist eine Gruppe für den Schlüsselaustausch in TLS 1.3 mit dem Codepoint 0x11EC (4588). Die Gruppe führt ML-KEM-768 und X25519 parallel aus und speist beide gemeinsamen Geheimnisse in den Key Schedule ein. Standardisiert ist sie in RFC 10024 (August 2026). Chrome, Firefox, Apples Netzwerk-APIs in den Betriebssystemen der Version 26, OpenSSL 3.5, Go 1.24+ und JDK 27 bieten sie standardmäßig an. Führe openssl s_client -connect example.com:443 -brief mit OpenSSL 3.5 aus und achte auf Negotiated TLS1.3 group: X25519MLKEM768. Das Verfahren schützt aufgezeichneten Datenverkehr gegen einen künftigen Quantencomputer. Für die Authentifizierung leistet es nichts – die beruht weiterhin auf RSA- oder ECDSA-Zertifikaten.

Was der Name aussagt

TLS 1.3 handelt den Schlüsselaustausch über Named Groups aus. Der Client listet die Gruppen, die er unterstützt, in der Erweiterung supported_groups auf und sendet in key_share öffentliche Schlüssel für eine oder mehrere davon. Der Server wählt eine Gruppe und antwortet mit seinem eigenen Key Share. Jahrelang kamen realistisch nur X25519 und P-256-ECDH infrage. Beide fallen auf einem ausreichend großen Quantencomputer dem Shor-Algorithmus zum Opfer, und heute aufgezeichneter Datenverkehr lässt sich entschlüsseln, sobald es eine solche Maschine gibt. Das ist das Problem harvest now, decrypt later (jetzt speichern, später entschlüsseln).

Eine hybride Gruppe löst es, ohne alles auf neue Mathematik zu setzen. X25519MLKEM768 führt in einer einzigen Aushandlung zwei Schlüsseleinigungen aus:

• ML-KEM-768, das Schlüsselkapselungsverfahren auf Basis von Modulgittern aus FIPS 203 (August 2024) mit Parametern der Kategorie 3. Dieser Teil widersteht Quantenangriffen.
• X25519, die Diffie-Hellman-Funktion auf elliptischen Kurven aus RFC 7748, die auf eine lange Geschichte der Kryptoanalyse zurückblickt und die neuere Komponente absichert.

Die allgemeine Konstruktion beschreibt RFC 9954 (Hybrid Key Exchange in TLS 1.3, Juli 2026). Das erklärte Ziel ist Sicherheit, „selbst wenn ein Weg gefunden wird, die Verschlüsselung aller Komponentenalgorithmen bis auf einen zu brechen“. Die konkreten Gruppen definiert RFC 10024 (August 2026):

In älteren Mitschnitten taucht möglicherweise X25519Kyber768Draft00 mit dem Codepoint 0x6399 (25497) auf. Das war die Kyber-Hybridgruppe aus der Zeit vor dem Standard; Chrome hat sie als Erstes ausgeliefert. FIPS 203 hat den Algorithmus in kleinen, aber inkompatiblen Punkten geändert, deshalb ersetzte Chrome 131 ihn durch 0x11EC und entfernte die Entwurfsgruppe. Googles Ankündigung nennt den Grund, warum Chrome nicht beide unterstützt hat: „Post-Quanten-Kryptografie ist zu groß, um zwei Post-Quanten-Key-Share-Vorhersagen gleichzeitig anbieten zu können.“ RFC 10024 erklärt die Codepoints der Entwürfe für obsolet.

Was im Key Share steckt

Der hybride Key Share ist eine einfache Verkettung der beiden Komponentenwerte, ohne innere Längenpräfixe. Die Größen legen FIPS 203 und RFC 7748 fest, daher lässt sich jedes Feld allein über seine Länge prüfen:

Achte auf die Reihenfolge. Der Name beginnt mit X25519, die Bytes beginnen aber mit ML-KEM. Laut RFC 10024 wurde die Reihenfolge gegenüber der Namenskonvention „umgekehrt“, und zwar „aus historischen Gründen“. Abschnitt 5 des RFC nennt außerdem einen Compliance-Grund: NIST SP 800-56C erlaubt ein kombiniertes Geheimnis in einer FIPS-zugelassenen Schlüsselableitung nur, wenn die erste Eingabe aus einem zugelassenen Verfahren stammt, und in diesem Paar ist das ML-KEM. Die beiden hybriden Gruppen mit NIST-Kurven stellen den ECDH-Key-Share aus demselben Grund an den Anfang. Ein Parser, der das Feld bei Byte 32 statt bei Byte 1.184 teilt, scheitert jedes Mal.

Dies ist ein echtes ClientHello von OpenSSL 3.5.7 an cloudflare.com, aufgezeichnet mit -trace am 20. Oktober 2026 (Schlüsselbytes gekürzt):

Sent TLS Record
  Content Type = Handshake (22)
  Length = 1551
    ClientHello, Length=1547
        extension_type=supported_groups(10), length=18
          X25519MLKEM768 (4588)
          ecdh_x25519 (29)
          secp256r1 (P-256) (23)
          ecdh_x448 (30)
          secp384r1 (P-384) (24)
          secp521r1 (P-521) (25)
          ffdhe2048 (256)
          ffdhe3072 (257)
        extension_type=key_share(51), length=1258
            NamedGroup: X25519MLKEM768 (4588)
            key_exchange:  (len=1216): A4696B297C695DEA602FB55157BC359F...
            NamedGroup: ecdh_x25519 (29)
            key_exchange:  (len=32): 919D957E3D7E402ECF27C3DD0B38DDA0...

Der Client sendet zwei Key Shares: den hybriden und einen reinen X25519-Key-Share. Das ist die Voreinstellung von OpenSSL 3.5. Go 1.27.3 sendet dasselbe Paar, ebenso Chromium 156, das zusätzlich einen GREASE-Eintrag einfügt; sein ClientHello kommt als Record mit 1.704 Byte an. JEP 527 sieht für JDK 27 dasselbe Paar vor. Der reine Key Share kostet 32 Byte und erlaubt einem Server, der 0x11EC nicht kennt, den Handshake in einem Roundtrip abzuschließen, statt einen weiteren Key Share anzufordern. Die Erweiterung key_share geht exakt auf: 2 Byte Listenlänge, dann 2 + 2 + 1.216 für den hybriden Eintrag und 2 + 2 + 32 für X25519, insgesamt 1.258. Der Server hat die hybride Gruppe gewählt:

    ServerHello, Length=1206
        extension_type=key_share(51), length=1124
            NamedGroup: X25519MLKEM768 (4588)
            key_exchange:  (len=1120): C01BC77BB1F9985B0DE82CDD1D0DD14B...

Zum Vergleich: Derselbe Client sendet mit -groups X25519 ein ClientHello von 313 Byte. Die hybride Gruppe fügt in jeder Richtung etwa 1,2 KB hinzu, und diese Größe ist die Ursache der meisten Kompatibilitätsprobleme (siehe unten).

Von zwei Geheimnissen zu einem Key Schedule

Jede Seite führt zwei unabhängige Operationen aus:

1. Der Client erzeugt ein ML-KEM-768-Schlüsselpaar und ein X25519-Schlüsselpaar und sendet beide öffentlichen Schlüssel.
2. Der Server führt mit dem ML-KEM-Schlüssel die Kapselung aus. Er erhält ein Geheimnis von 32 Byte und ein Chiffrat von 1.088 Byte. Außerdem führt er X25519 mit seinem eigenen ephemeren Schlüssel aus und sendet dann das Chiffrat und seinen öffentlichen X25519-Schlüssel.
3. Der Client entkapselt das Chiffrat, gewinnt so dasselbe ML-KEM-Geheimnis zurück und schließt X25519 auf seiner Seite ab.
4. Beide Seiten verketten die Ergebnisse zu 64 Byte und setzen diesen Wert dort ein, wo TLS 1.3 normalerweise das (EC)DHE-Geheimnis verwendet: als Eingabe für das HKDF-Extract, das das Handshake Secret ableitet (RFC 9846 §7.1, die Überarbeitung von TLS 1.3 vom Juli 2026, die RFC 8446 ablöst).

Alles danach ist gewöhnliches TLS 1.3. Die Cipher Suites, das Zertifikat, CertificateVerify und die Traffic-Schlüssel bleiben unverändert. RFC 10024 ergänzt Prüfschritte, die Implementierungen ausführen müssen. Diese Schritte prüfen den Kapselungsschlüssel so, wie FIPS 203 es verlangt, weisen ein Chiffrat mit falscher Länge zurück und brechen ab, wenn das X25519-Ergebnis nur aus Nullen besteht. Jeder dieser Fehler beendet den Handshake mit einem Alert illegal_parameter oder internal_error.

Das Sicherheitsargument ist kurz. Ein Angreifer, der den Handshake aufzeichnet, muss beide Geheimnisse wiederherstellen, um das Handshake Secret zu berechnen. X25519 mit einem künftigen Quantencomputer zu brechen, genügt nicht, solange ML-KEM hält. Eine kryptoanalytische Überraschung beim jungen gitterbasierten Verfahren genügt nicht, solange X25519 hält. Wenn du Kapselung und Entkapselung mit echten Schlüsseln sehen willst: Das ML-KEM-Lab führt beides in deinem Browser aus.

Wer die Gruppe standardmäßig aktiviert

Stand Oktober 2026 bieten alle großen Clients die Gruppe standardmäßig an:

Alles, was gegen OpenSSL 3.5 gelinkt ist, übernimmt die Voreinstellung ebenfalls, solange die eigene Konfiguration die Gruppenliste nicht überschreibt. Das gilt für die Pakete von Debian 13 und für Node.js 24, das ein eigenes OpenSSL 3.5 mitbringt. Unter Debian 13 schloss das Python-Modul ssl einen Handshake mit einem openssl s_server -groups X25519MLKEM768 ab, der nichts anderes akzeptiert, und curl und nginx handelten das Hybridverfahren ohne zusätzliche Konfiguration aus. Apples Seite TLS-Sicherheit nennt eine Lücke: „TLS-Clients, die die SecureTransport-APIs verwenden, können TLS 1.3 nicht nutzen“. Apps, die noch auf dieser API aufsetzen, bekommen also keinen hybriden Schlüsselaustausch.

Auf der Serverseite endet bereits ein großer Teil des HTTPS-Datenverkehrs auf Stacks, die das Hybridverfahren wählen, wenn der Client es anbietet. Eine Abfrage mit OpenSSL 3.5.7 am 20. Oktober 2026 handelte X25519MLKEM768 mit cloudflare.com, google.com, www.amazon.com, www.microsoft.com, www.apple.com und example.com aus, reines X25519 dagegen mit github.com und letsencrypt.org.

Server, Client und Browser prüfen

Über die Befehlszeile. Die Ausgabe von -brief in OpenSSL 3.5 nennt die Gruppe direkt:

$ openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -brief </dev/null
Connecting to 104.16.132.229
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=cloudflare.com
Hash used: SHA256
Signature type: ecdsa_secp256r1_sha256
Verification: OK
Negotiated TLS1.3 group: X25519MLKEM768
DONE

Bei einem Server, der eine klassische Gruppe wählt, zeigt die Ausgabe stattdessen Peer Temp Key: X25519, 253 bits. Um zu testen, ob ein Server das Hybridverfahren überhaupt beherrscht, biete nichts anderes an. Ein rein klassischer Server bricht den Handshake dann ab:

$ openssl s_client -groups X25519MLKEM768 -connect github.com:443 -servername github.com -brief </dev/null
...:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:...:SSL alert number 40

Nutze diese Abfrage nur zum Testen. Ein echter Client, der ausschließlich das Hybridverfahren anbietet, gibt Kompatibilität ohne jeden Gewinn auf. Ein auf OpenSSL 3.5 gebautes curl gibt die Gruppe in seiner ausführlichen Verbindungszeile aus:

$ curl -sv -o /dev/null https://www.google.com/ 2>&1 | grep 'SSL connection'
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey

Im Code. Go 1.25 und neuer stellen die ausgehandelte Gruppe als ConnectionState().CurveID bereit, und Node.js 24 meldet sie über getEphemeralKeyInfo():

conn, err := tls.Dial("tcp", "cloudflare.com:443", &tls.Config{ServerName: "cloudflare.com"})
if err != nil {
	log.Fatal(err)
}
fmt.Println(conn.ConnectionState().CurveID) // X25519MLKEM768 (Go 1.27.3)

import tls from "node:tls";
const socket = tls.connect({ host: "cloudflare.com", port: 443, servername: "cloudflare.com" }, () => {
  console.log(socket.getEphemeralKeyInfo()); // { type: 'TLSGroup', name: 'X25519MLKEM768', size: undefined } (Node 24.22.0)
  socket.end();
});

Im Browser. Chrome zeigt die Gruppe in den DevTools an, in den Verbindungsdetails des Bereichs „Sicherheit“. Programmatisch steht derselbe Wert als securityDetails.keyExchangeGroup im Ereignis Network.responseReceived des DevTools-Protokolls bereit. Headless Chromium 156 meldete am 20. Oktober 2026 X25519MLKEM768 für www.cloudflare.com und X25519 für github.com. Unter macOS 26 empfiehlt Apple nscurl --tls-diagnostics https://your.host. Um zu sehen, was dein Browser sendet, öffne den Post-Quanten-Browser-Check.

Auf deinem Server aktivieren

Läuft OpenSSL 3.5 darunter, stimmt die Voreinstellung bereits. Verloren geht sie meist durch eine explizite Gruppenliste, die aus einer älteren Härtungsanleitung kopiert wurde. Dieser Test mit nginx 1.30.5 unter Debian 13 (OpenSSL 3.5.7) ändert nur die Zeile ssl_ecdh_curve und fragt mit openssl s_client -brief ab:

--- no ssl_ecdh_curve (OpenSSL default list)
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
--- ssl_ecdh_curve X25519:prime256v1:secp384r1;
Protocol version: TLSv1.3
Peer Temp Key: X25519, 253 bits
--- ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

Die Abhilfe ist also eins von beidem: die Zeile entfernen oder X25519MLKEM768 darin an die erste Stelle setzen. Ältere OpenSSL-Versionen kennen den Namen nicht, aktualisiere also zuerst die TLS-Bibliothek. nginx 1.24.0 mit OpenSSL 1.1.1w weist eine solche Zeile (hier ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;) mit nginx: [emerg] SSL_CTX_set1_curves_list("X25519MLKEM768:X25519:prime256v1") failed zurück. Andere Server folgen demselben Muster unter anderen Namen: SSLOpenSSLConfCmd Groups in Apache httpd, curves in HAProxy, CurvePreferences in Go, jdk.tls.namedGroups in Java. Wenn du einen Ausgangspunkt für einen bestimmten Server brauchst: Der TLS-Konfigurationsgenerator erstellt Konfigurationen, in denen die hybriden Gruppen bereits eingetragen sind.

Zwei weitere Stellen geraten leicht in Vergessenheit:

• Der Origin hinter einem CDN oder Load Balancer. Die Verbindung des Browsers endet am Edge, und die Verbindung vom Edge zu deinem Origin ist eine eigene TLS-Sitzung mit eigener Aushandlung. Aufgezeichneter Datenverkehr auf dieser zweiten Strecke lässt sich genauso sammeln und später entschlüsseln.
• Internes TLS zwischen Diensten. Go-Dienste bekommen das Hybridverfahren über die Version der Toolchain. Java-Dienste bekommen es mit JDK 27, in dem JEP 527 die hybriden Gruppen ergänzt hat. Alles, was CurvePreferences, jdk.tls.namedGroups oder eine andere explizite Gruppenliste fest vorgibt, bekommt nichts davon, bis jemand diese Liste ändert.

Key-Share-Vorhersage und HelloRetryRequest

Ein Client muss unter TLS 1.3 raten, welche Gruppe der Server wählen wird, und vorab einen Key Share dafür senden. Rät er falsch, antwortet der Server mit einem HelloRetryRequest, der die gewünschte Gruppe nennt, und der Client beginnt von vorn. Das kostet einen vollen Roundtrip. Bei Post-Quanten-Key-Shares ist die richtige Vermutung wichtiger, denn einen Key Share von 1.216 Byte „für alle Fälle“ zu senden, ist nicht umsonst. Du kannst die Wiederholung beobachten, indem du OpenSSL anweist, das Hybridverfahren aufzulisten, aber nur für X25519 einen Key Share zu senden:

    ClientHello, Length=315
        extension_type=key_share(51), length=38
            NamedGroup: ecdh_x25519 (29)
    ServerHello, Length=84                      <- HelloRetryRequest
        extension_type=key_share(51), length=2
            NamedGroup: X25519MLKEM768 (4588)
    ClientHello, Length=1499
        extension_type=key_share(51), length=1222
            NamedGroup: X25519MLKEM768 (4588)
    ServerHello, Length=1206
Negotiated TLS1.3 group: X25519MLKEM768

Der Server bevorzugte das Hybridverfahren, obwohl der Client X25519 zuerst aufgelistet hatte, und forderte deshalb eine Wiederholung an. In Gruppen-Strings von OpenSSL 3.5 markiert ein vorangestelltes * die Gruppen, die schon in der ersten Nachricht des Clients einen Key Share bekommen. -groups '*X25519:*X25519MLKEM768' sendet beide Key Shares in einem ClientHello von 1.535 Byte und vermeidet die Wiederholung. Die Voreinstellungen der großen Clients senden aus demselben Grund beide. Ein Entwurf der TLS-Arbeitsgruppe, draft-ietf-tls-key-share-prediction, lässt Server ihre bevorzugten Gruppen in HTTPS-Einträgen im DNS veröffentlichen, damit Clients beim ersten Mal richtig raten. Im Oktober 2026 war er noch ein Internet-Draft.

Was kaputtgeht: große ClientHellos und alte Middleboxes

Das oben gemessene ClientHello füllt einen TLS-Record mit 1.551 Byte Payload. Mit den Headern von Record, TCP und IP passt es auf einem typischen Pfad mit einer MTU von 1.500 Byte nicht mehr in ein Paket. Die Spezifikation hat das schon immer erlaubt, aber manche Implementierungen gingen davon aus, dass das erste read() vom Socket das ganze ClientHello liefert. Solche Implementierungen scheitern, sobald das Hybridverfahren es auf zwei Segmente verteilt.

Das Projekt tldr.fail verfolgt diese Fehlerklasse. Es beschreibt Server, die „nicht darauf vorbereitet sind, read() mehr als einmal aufrufen zu müssen, um das gesamte ClientHello zu lesen“. Auf seiner Liste stehen Proxys mit TLS-Inspektion, Firewalls und Load Balancer mehrerer Hersteller. Für einige gibt es inzwischen Patches, andere sind als unbekannt markiert. Die Symptome sehen nach Netzwerkproblemen aus, nicht nach Kryptografie: ERR_CONNECTION_RESET oder ERR_SSL_PROTOCOL_ERROR in Chrome, Timeouts im Handshake oder Resets direkt nach dem ClientHello. Oft ist der Fehler nur bei Clients sichtbar, die das Hybridverfahren senden. Apple warnt in den Hinweisen zu den Betriebssystemen der Version 26 vor demselben Fehler: Geräte erreichen möglicherweise einige ältere Server nicht, deren TLS-Code „große ClientHello-Nachrichten nicht lesen kann“.

Wenn du darauf stößt:

1. Finde das Gerät, das die Verbindung zurücksetzt. Vergleiche openssl s_client -groups X25519 mit der Standard-Gruppenliste über denselben Pfad. Scheitert nur das große ClientHello, liegt das Problem an der Größe, nicht am Zertifikat.
2. Aktualisiere oder ersetze dieses Gerät. Wer das Hybridverfahren auf den Clients abschaltet, nimmt jeder Verbindung den Schutz, auch denen, die funktioniert haben.
3. Nutze die clientseitigen Schalter nur als Notbehelf. Go hat GODEBUG=tlsmlkem=0, und die Versionshinweise zu Go 1.24 nennen ihn für „fehlerhafte TLS-Server, die große Records nicht korrekt verarbeiten“. Chrome hatte die Unternehmensrichtlinie PostQuantumKeyAgreementEnabled, die Google als „vorübergehende Maßnahme“ bezeichnete, die „irgendwann nach Google Chrome Version 145 entfernt wird“. Prüfe, ob deine Chrome-Version sie noch berücksichtigt, bevor du damit planst.

Für Proxys, die TLS terminieren, gilt noch ein Hinweis. Ein Proxy, der Datenverkehr entschlüsselt, führt zwei Handshakes aus. Was dein Laptop mit dem Proxy aushandelt, sagt nichts über die Verbindung des Proxys zur Außenwelt aus. Diese Strecke ist nur dann mit Post-Quanten-Verfahren geschützt, wenn der TLS-Stack des Proxys selbst das Hybridverfahren unterstützt und bevorzugt.

Was X25519MLKEM768 nicht schützt

X25519MLKEM768 schützt die Vertraulichkeit gegen einen Gegner, der Datenverkehr jetzt aufzeichnet und später entschlüsselt. Die Authentifizierung im Handshake stellt es nicht auf Post-Quanten-Verfahren um. Der Server weist seine Identität weiterhin mit einem RSA- oder ECDSA-Zertifikat und einer Signatur in CertificateVerify nach. Wer diese Signaturen mit einem Quantencomputer fälschen kann, könnte sich in einer laufenden Verbindung als der Server ausgeben. Diese Bedrohung besteht erst, wenn es einen solchen Computer gibt. Deshalb kam der Schlüsselaustausch zuerst an die Reihe, und Signaturen sind eine eigene, langsamere Migration. Die anderen Artikel dieser Reihe behandeln diese Arbeit: ML-DSA-Schlüssel und -Signaturen in ML-DSA für Entwickler und den Gesamtplan samt Inventar und Fristen in Post-Quanten-Migration 2026.

Auch für Datenverkehr, der nicht über TLS 1.3 läuft, leistet X25519MLKEM768 nichts. Verbindungen über TLS 1.2, SSH-Sitzungen und VPN-Tunnel haben ihren eigenen Schlüsselaustausch und ihre eigenen Upgrade-Pfade. Finde heraus, welche deiner Verbindungen noch TLS 1.2 aushandeln, bevor du sie als geschützt einstufst.

Quellen

• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 (August 2026). Gruppendefinitionen, Byte-Reihenfolge, Prüfschritte, IANA-Codepoints.
• RFC 9954: Hybrid Key Exchange in TLS 1.3 (Juli 2026).
• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024).
• RFC 9846 §7.1: der Key Schedule von TLS 1.3.
• Google Security Blog, A new path for Kyber on the web (September 2024).
• Apple Support, Prepare your network for quantum-secure encryption in TLS, sowie der Leitfaden „Apple-Plattformsicherheit“.
• OpenSSL 3.5 NEWS.md, Versionshinweise zu Go 1.24 und 1.26, JEP 527.
• tldr.fail: der Fehler mit großen ClientHellos und die betroffenen Produkte.

Alle Befehlsausgaben auf dieser Seite stammen aus Containern vom 20. Oktober 2026: OpenSSL 3.5.7, curl 8.14.1, Node.js 24.22.0 und Debians Python 3 in node:24.22.0-trixie, Go 1.27.3 in golang:1.27.3-trixie, nginx 1.30.5 in nginx:1.30.5, nginx 1.24.0 mit OpenSSL 1.1.1w in nginx:1.24.0 und Chromium 156 in mcr.microsoft.com/playwright:v1.64.1-noble.