Zwei Post-Quanten-Hybride erreichen Endpunkte heute. Beide kombinieren X25519 und ML-KEM-768. Die Größen auf dem Draht sind identisch: 1216 Byte Client-Share, 1120 Byte Server-Share oder Chiffretext. Die Namen klingen austauschbar. Die Konstruktionen sind es nicht.
Das eine gegen das andere zu tauschen bricht. Einen X25519MLKEM768-Chiffretext mit einem X-Wing-Decapsulator zu entpacken, liefert das falsche gemeinsame Geheimnis, weil die Combiner sich unterscheiden. Herstellerdokumentation behandelt sie routinemäßig als Synonyme. Sie in einem Migrationsplan so zu behandeln, ist ein Fehler.
X25519MLKEM768 ist eine TLS-1.3-Named-Group
Spezifiziert in draft-kwiatkowski-tls-ecdhe-mlkem. IANA-Codepoint 0x11EC. Das ClientHello bewirbt die Gruppe in supported_groups und sendet einen key_share von ML-KEM-768.encaps_key || X25519.ephemeral_share, 1216 Byte. Das ServerHello gibt X25519.ephemeral_share || ML-KEM-768.ciphertext zurück, 1120 Byte. Das gemeinsame Geheimnis ist ss_MLKEM || ss_X25519, 64 Byte, das als (EC)DHE-Eingabe für HKDF-Extract in den bestehenden TLS-1.3-Schlüsselplan eingespeist wird.
ML-KEM steht aus einem bestimmten Grund an erster Stelle in der Konkatenation: NIST SP 800-56Cr2 genehmigt HKDF mit zwei gemeinsamen Geheimnissen nur, wenn das erste von einem FIPS-zugelassenen Verfahren erzeugt wird. ML-KEM-768 ist FIPS 203. X25519 ist nicht FIPS-zugelassen. Die Reihenfolge erhält den FIPS-Ableitungspfad.
Der Combiner ist einfache Konkatenation. Die Nicht-Malleabilität des resultierenden Schlüsselplans ist keine Eigenschaft des Combiners allein. Sie kommt vom TLS-1.3-Transcript-Hash, der den gesamten Handshake in jedes abgeleitete Geheimnis einbindet. Entfernt man das Transkript, trägt der Combiner allein nicht die Bindungseigenschaften, die eine allgemeine KEM benötigt.
X-Wing ist eine allgemeine KEM
Spezifiziert in draft-connolly-cfrg-xwing-kem, derzeit Revision 10 (März 2026, läuft September 2026 aus). Verkapselungsschlüssel 1216 Byte, Chiffretext 1120 Byte, gemeinsames Geheimnis 32 Byte.
Der Combiner ist ein einzelner SHA3-256-Hash:
Combiner(ss_M, ss_X, ct_X, pk_X) =
SHA3-256(ss_M || ss_X || ct_X || pk_X || XWingLabel)
XWingLabel = 0x5c2e2f2f5e5c // ASCII "\./" + "/^\"
Das Hashen des X25519-Chiffretextes und des öffentlichen X25519-Schlüssels in den Combiner verleiht X-Wing die Bindungseigenschaften MAL-BIND-K-PK und MAL-BIND-K-CT. Bare ML-KEM-768 hat keine davon. Die Bindung ist das, was X-Wing sicher macht, außerhalb eines umgebenden Transkripts verwendet zu werden, was der ganze Sinn der Bezeichnung „allgemein“ ist.
Sicherheitsbeweis in IACR ePrint 2024/039: X-Wing ist IND-CCA-sicher im QROM, wenn entweder X25519 oder ML-KEM-768 sicher ist. 128-Bit-Sicherheitsziel, NIST-PQC-Level 1.
Nebeneinander
| X25519MLKEM768 | X-Wing | |
|---|---|---|
| Spezifikation | draft-kwiatkowski-tls-ecdhe-mlkem | draft-connolly-cfrg-xwing-kem-10 |
| Einsatzfläche | TLS-1.3-Named-Group | HPKE, X.509, allgemein |
| Codepoint | TLS 0x11EC | HPKE 0x647a (beantragt, draft-10) |
| Combiner | Konkatenation, dann TLS-Schlüsselplan | SHA3-256 über ss_M, ss_X, ct_X, pk_X, Label |
| Client-Share | 1216 Byte | 1216 Byte (Verkapselungsschlüssel) |
| Server-Share | 1120 Byte | 1120 Byte (Chiffretext) |
| Gemeinsames Geheimnis | 64 Byte (konkateniert) | 32 Byte (gehasht) |
| Bindung | über TLS-Transkript, nicht Combiner | MAL-BIND-K-PK, MAL-BIND-K-CT im Combiner |
| FIPS-Pfad | über SP-800-56Cr2-HKDF-Ableitung | Keine FIPS-Konstruktion |
Sie sind nicht austauschbar
Aus dem X-Wing-Draft, Abschnitt 1.5.1:
There is also a different KEM called X25519Kyber768Draft00 which is used in TLS. This one should not be used outside of TLS, as it assumes the presence of the TLS transcript to ensure non malleability.
Dieselbe Einschränkung gilt für X25519MLKEM768. Es ist eine TLS-Konstruktion. Hebt man das 64-Byte-gemeinsame-Geheimnis aus dem TLS-Schlüsselplan heraus und verwendet es anderswo, wandern die Bindungseigenschaften nicht mit.
In die andere Richtung ist X-Wing keine TLS-Named-Group. Es hat keinen 0x11EC oder äquivalenten TLS-Codepoint. TLS-1.3-Implementierungen können es nicht aushandeln. Der Versuch, X-Wing in einen TLS-Stack einzubauen, erfordert entweder eine neue TLS-Erweiterung oder den Missbrauch eines nicht zugewiesenen Codepoints, und die Interop-Story ist nicht vorhanden.
Historischer Übergang
X25519Kyber768Draft00, Codepoint 0x6399, war der Hybrid, den Chrome, Firefox und Cloudflare 2023 und 2024 einsetzten. Es verwendete die Kyber-Runde-3-Spezifikation, die im August 2024 durch FIPS 203 ML-KEM abgelöst wurde. Der Codepoint und das Drahtformat änderten sich. X25519MLKEM768 bei 0x11EC ist die FIPS-203-Version. Paketmitschnitte und Herstellerdokumentation aus 2023 und 2024, die Kyber oder Codepoint 0x6399 referenzieren, beschreiben die veraltete Konstruktion.
Einen Endpunkt heute zu untersuchen und X25519Kyber768Draft00 noch beworben zu sehen, ist ein Signal. Der Hersteller hat nicht auf ML-KEM aktualisiert und betreibt veralteten Code.
NIST-Position
SP 800-227, finalisiert im September 2025. Abschnitt 4.6 zu Multi-Algorithmus-KEMs und PQ/T-Hybriden nennt X-Wing als das konkrete Beispiel einer zusammengesetzten KEM. Kein FIPS-Mandat. Keine TLS-Empfehlung. Es ist die einzige genannte Konstruktion im Dokument, was so nah an einer Befiirwortung kommt, wie NIST sie außerhalb von FIPS 203 anbietet.
TLS-Hybrid-Codepoints werden von der IETF-TLS-Arbeitsgruppe über die IANA verwaltet. X25519MLKEM768 liegt auf diesem Pfad. NIST SP 800-227 nennt es nicht.
Deployment-Status
X25519MLKEM768 in TLS: Standard in Chrome 131 (November 2024, als Chrome seinen Standard von X25519Kyber768Draft00 bei 0x6399 auf X25519MLKEM768 bei 0x11EC umstellte), Standard in Edge 131, Firefox 132, Cloudflare-Edge seit März 2024, OpenSSL 3.5 und höher, BoringSSL, wolfSSL. Safari Technology Preview hat es; die stabile Version hinkt hinterher.
X-Wing in KEM-Kontexten: Go über filippo.io/mlkem768/xwing, Rust über die x-wing-Crate, Google Cloud KMS unter dem Algorithmusbezeichner kem-xwing, HPKE-Implementierungen verfolgen den Draft. OpenSSL-Provider-Arbeit ist in Arbeit. Keine ernsthafte TLS-Implementierung liefert X-Wing aus, weil X-Wing keine TLS-Named-Group ist.
Geltungsbereich
Dies ist Schlüsselaustausch. Signaturen sind eine separate Migration mit separaten Algorithmen: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), Falcon (FIPS 206 Draft). Ein Hersteller mit X25519MLKEM768 auf dem Draht signiert möglicherweise immer noch mit klassischem RSA oder ECDSA. Vertraulichkeitsaufstellung und Authentifizierungsaufstellung sind unabhängig und müssen separat gemessen werden.
Selbst testen
TLS-Seite, OpenSSL 3.5 oder höher:
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3
Wenn der Handshake gelingt und das ServerHello key_share-Gruppe 0x11EC zurückgibt, handelt der Endpunkt den Hybrid aus. Wenn der Server auf X25519 oder secp256r1 zurückfällt, tut er es nicht.
KEM-Seite, Go:
import "filippo.io/mlkem768/xwing"
dk, ek, _ := xwing.GenerateKeyPair(rand.Reader)
ct, ss1, _ := xwing.Encapsulate(rand.Reader, ek)
ss2, _ := xwing.Decapsulate(dk, ct)
// ss1 == ss2, 32 Byte
Die beiden Operationen erzeugen unterschiedliche gemeinsame Geheimnisse aus denselben X25519- und ML-KEM-768-Primitiven. Das ist die Demonstration: gleiche Eingaben, unterschiedliche Ausgaben, weil die Combiner sich unterscheiden.
Was Sie Hersteller fragen sollten
- Welche TLS-Named-Groups bewirbt Ihr Endpunkt, und was ist der aktuelle Codepoint?
- Ist die beworbene Gruppe X25519MLKEM768 bei 0x11EC oder das veraltete X25519Kyber768Draft00 bei 0x6399?
- Wenn Sie eine KEM- oder HPKE-API offenlegen, ist es X-Wing, der generische Combiner von draft-ounsworth-cfrg-kem-combiners oder etwas Proprietäres?
- Sind Ihre Signaturen post-quantum? ML-DSA, SLH-DSA, hybrid mit ECDSA oder RSA, oder noch rein klassisch?
- Wenn Ihr TLS X25519MLKEM768 bewirbt und Ihr KMS X-Wing bewirbt, können Sie bestätigen, dass es zwei verschiedene Konstruktionen mit denselben zugrunde liegenden Primitiven sind, nicht dieselbe Konstruktion unter zwei Namen?
Frage fünf ist die, die Hersteller am häufigsten falsch beantworten. [PQ]probe erfasst die TLS-Named-Group, die der Endpunkt tatsächlich aushandelt, und zeigt den Codepoint direkt an; die KEM- und HPKE-Flächen erfordern eine separate Überprüfung der Produktdokumentation, des SDK-Codes und der API-Antworten.