ML-KEM vs. Kyber: Was sich zwischen dem Entwurf und FIPS 203 geändert hat

CRYSTALS-Kyber und ML-KEM sind nicht zwei verschiedene Algorithmen. ML-KEM ist die standardisierte Form von CRYSTALS-Kyber, die NIST am 13. August 2024 als FIPS 203 veröffentlicht hat. Die Änderung ist nicht nur kosmetisch: FIPS 203 ist eine Spezifikation mit eigenen Namen für die Parametersätze, eigenen Schlüsselformaten und eigenen Validierungsregeln, und eine Implementierung der früheren Wettbewerbseinreichung ist nicht mit einer ML-KEM-Implementierung interoperabel. Deshalb ist in TLS die vorstandardisierte Gruppe X25519Kyber768Draft00 (Codepoint 0x6399) obsolet und muss durch die ML-KEM-Gruppen ersetzt werden.

Ein Design, zwei Namen, eine verabschiedete Spezifikation

Ein KEM (Key Encapsulation Mechanism) ist die Komponente eines Handshakes, mit der sich zwei Parteien auf ein gemeinsames Geheimnis einigen. CRYSTALS-Kyber war der Name des gitterbasierten KEM, das beim NIST-Standardisierungsprozess für Post-Quanten-Kryptografie eingereicht wurde. Mit der Veröffentlichung des finalen Standards benannte NIST den Algorithmus in ML-KEM um, kurz für Module-Lattice-Based Key-Encapsulation Mechanism, und spezifizierte ihn in FIPS 203. Am selben Tag erschienen auch FIPS 204 (ML-DSA, Signaturen) und FIPS 205 (SLH-DSA, zustandslose hashbasierte Signaturen).

Im Gespräch bezeichnen Kyber und ML-KEM dieselbe Familie von Designs. Im Code, in einer Gruppenliste oder in einem Compliance-Dokument sind sie jedoch nicht austauschbar. Nur ML-KEM in der Spezifikation von FIPS 203 ist ein verabschiedeter Standard. Alles, was noch als Kyber, Kyber768 oder Draft00 bezeichnet ist, stammt aus der Zeit davor. Unsere Referenzseite zu ML-KEM verfolgt den Standard und seinen Status, und die Seite zum Kyber-Entwurf verfolgt die vorstandardisierten Gruppen, die nun aus Konfigurationen entfernt werden sollten.

Was der Übergang vom Entwurf zum finalen Standard geändert hat

FIPS 203 wurde zunächst als öffentlicher Entwurf zur Kommentierung veröffentlicht, bevor NIST den finalen Text herausgab. Drei Kategorien von Änderungen sind für Entwickler und Architekten relevant.

Namen und Parametersätze

Aus Kyber512, Kyber768 und Kyber1024 wurden ML-KEM-512, ML-KEM-768 und ML-KEM-1024. FIPS 203 spezifiziert genau diese drei Parametersätze. Eine Build-Option, eine Konstante oder ein Testvektor, der noch einen Kyber-Namen trägt, ist ein Hinweis darauf, dass der Code nicht aktualisiert wurde, und nicht bloß darauf, dass jemand eine alte Bezeichnung beibehalten hat.

Spezifikationsdetails, die die Interoperabilität brechen

Der finale Standard unterscheidet sich von der früheren Wettbewerbseinreichung in Spezifikationsdetails, darunter die Schlüsselerzeugung, die Schlüsselkodierung und die Ableitung des gemeinsamen Geheimnisses. Diese Details sind in FIPS 203 normativ festgelegt und sollten dort nachgelesen statt aus zweiter Hand zusammengefasst werden. Die praktische Konsequenz ist einfach und absolut: Eine Gegenstelle mit vorstandardisiertem Kyber und eine Gegenstelle mit ML-KEM leiten nicht dasselbe gemeinsame Geheimnis ab. Es gibt keine Aushandlung zwischen ihnen, keinen Downgrade-Pfad und keine teilweise Kompatibilität. Der Handshake schlägt fehl, oder die Gruppe wird schlicht nie ausgewählt.

Regeln, die eine Implementierung einhalten muss

FIPS 203 spezifiziert außerdem Prüfungen, die eine Implementierung an empfangenem Schlüsselmaterial vornimmt, bevor es verwendet wird, und legt das Verhalten der Dekapselung bei ungültiger Eingabe fest (implizite Zurückweisung, die statt eines Fehlers ein pseudozufälliges gemeinsames Geheimnis zurückgibt). Den Großteil dieser Last tragen die Autoren der Bibliotheken. Für Nutzer einer Bibliothek lautet die Lehre: Bevorzugen Sie eine gepflegte Implementierung, die ihre Konformität mit FIPS 203 ausweist, gegenüber einer Kopie von Referenzcode aus der Wettbewerbsphase, und prüfen Sie die Release Notes statt des Algorithmusnamens.

Die drei Parametersätze: 512, 768 und 1024

FIPS 203 ordnet die drei Parametersätze den NIST-Sicherheitskategorien zu. Die Zahl ist keine Schlüssellänge in Bit, sondern eine Bezeichnung für den Parametersatz.

Für allgemeines TLS und SSH hat sich das Ökosystem auf ML-KEM-768 innerhalb einer hybriden Konstruktion geeinigt. Wenn Sie Systeme im Geltungsbereich von NSA CNSA 2.0 betreiben, nennt die Suite ML-KEM-1024 zusammen mit ML-DSA-87, LMS oder XMSS, AES-256 sowie SHA-384 oder SHA-512. Die ausschließliche Nutzung wird bis Ende 2030 für Software- und Firmware-Signaturen sowie klassische Netzwerkausrüstung erwartet und bis Ende 2033 für Webbrowser und Server, Cloud-Dienste und Betriebssysteme. Andere Behörden formulieren ihre Positionen als Empfehlungen: BSI TR-02102-1 empfiehlt eine hybride Post-Quanten-Schlüsselvereinbarung, und ANSSI schreibt die Hybridisierung innerhalb ihres regulierten Bereichs vor, stellt aber klar, dass ihre Post-Quanten-Empfehlungen außerhalb davon noch keine regulatorischen Pflichten sind. Dieser Artikel dient der Information und ist keine Rechtsberatung.

TLS-Gruppen: was aktuell ist, was obsolet ist

Die Named Group ist der sichtbare Teil all dessen. Für ML-KEM existieren im IANA-Register nur die unten aufgeführten Codepoints, und nur einer davon ist der obsolete vorstandardisierte Eintrag.

Die hybriden Gruppen kombinieren eine klassische Schlüsselvereinbarung mit ML-KEM. So bleibt die Sitzung mindestens so stark wie der klassische Teil, falls eine Schwäche in der Gitterkonstruktion gefunden wird, und erhält zugleich Post-Quanten-Schutz gegen aufgezeichneten Datenverkehr. Diese Kombination ist für TLS 1.3 in RFC 10024 (August 2026) beschrieben. Aufgezeichneter Datenverkehr wird nur durch den Schlüsselaustausch geschützt; deshalb wird die Schlüsselvereinbarung zuerst migriert, und Zertifikate können später folgen. Die Seite zu X25519MLKEM768 beschreibt im Detail die Gruppe, die die meisten Server zuerst aktivieren sollten.

Was Sie in Bibliotheken, Servern und SSH prüfen sollten

Führen Sie zuerst rein lesende Prüfungen auf einem Staging-Host durch, bevor Sie eine Produktivkonfiguration anfassen.

OpenSSL

Für die ML-KEM-TLS-Gruppen ist OpenSSL 3.5 oder neuer erforderlich. Ein älterer Branch kann über einen Provider oder einen Distributionspatch noch eine Kyber-Entwurfsgruppe anbieten: Genau diesen Fall gilt es zu finden und zu beseitigen.

openssl version
openssl list -tls-groups | grep -i mlkem
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Lesen Sie in der Ausgabe von s_client die ausgehandelte Gruppe ab. Schlägt die Verbindung mit einem Handshake-Fehler fehl, während eine klassische Gruppe funktioniert, unterstützt der Server ML-KEM noch nicht.

Serverkonfiguration

Behalten Sie nach der hybriden Gruppe immer einen klassischen Fallback bei, damit ältere Clients weiterhin eine Verbindung aufbauen können. Bei nginx, gebaut gegen OpenSSL 3.5 oder neuer:

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

Syntax und unterstützte Werte unterscheiden sich zwischen Servern und zwischen Distributions-Builds; prüfen Sie daher anhand Ihrer eigenen Version. Unsere Anleitung zum Aktivieren von ML-KEM auf nginx, Apache, HAProxy und Caddy beschreibt die jeweilige Direktive.

SSH

OpenSSH 9.9 (19. September 2024) führte mlkem768x25519-sha256 ein, standardmäßig verfügbar. OpenSSH 10.0 (9. April 2025) machte es zur Standard-Schlüsselvereinbarung, und OpenSSH 10.1 (6. Oktober 2025) warnt über die standardmäßig aktivierte Option WarnWeakCrypto, wenn eine Verbindung eine Schlüsselvereinbarung aushandelt, die nicht post-quantensicher ist. Frühere Versionen ab OpenSSH 9.0 verwenden standardmäßig das hybride sntrup761x25519-sha512@openssh.com, das post-quantensicher ist, aber nicht ML-KEM.

ssh -V
ssh -Q kex | grep mlkem

Anwendungscode und Abhängigkeiten

• Durchsuchen Sie Ihre Repositories und Ihr Konfigurationsmanagement nach den Zeichenketten Kyber, kyber768, Draft00 und 0x6399. Jeder Treffer ist entweder toter Code oder eine aktive Fehlkonfiguration.
• Prüfen Sie fest hinterlegte Gruppenlisten in Load Balancern, CDNs, API-Gateways, Reverse Proxies und TLS-Terminatoren. Eine fest hinterlegte Liste ist der häufigste Grund, warum eine moderne Bibliothek dennoch eine klassische Gruppe aushandelt.
• Prüfen Sie in den Release Notes Ihrer Kryptobibliothek, nicht anhand des Algorithmusnamens, ob die Implementierung FIPS 203 folgt. Wo eine FIPS-Validierung für Sie relevant ist, prüfen Sie den Validierungsstatus des konkreten Moduls und der Version, die Sie ausliefern.
• Erfassen Sie in Ihrem Inventar den Parametersatz, nicht nur den Algorithmus: ML-KEM-768 und ML-KEM-1024 sind unterschiedliche Antworten auf die Frage eines Auditors, welchen Sie eingesetzt haben.

Prüfen Sie, was Ihre Server tatsächlich aushandeln

Am schnellsten erfahren Sie, ob eine Domain den Standard oder noch eine Entwurfsgruppe nutzt, indem Sie sich ansehen, was sie tatsächlich anbietet. Sie können Ihre Domain kostenlos mit PQC Status scannen: Der Scanner meldet die hybriden ML-KEM-Gruppen, die ein Server akzeptiert, die TLS-Versionen und Cipher Suites sowie die Zertifikatskette. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration. Er ist keine Zertifizierung und keine Compliance-Bestätigung. Der konkrete nächste Schritt zu diesem Thema: Stellen Sie sicher, dass jeder öffentliche Endpunkt X25519MLKEM768 mit klassischem Fallback anbietet, und entfernen Sie anschließend alle verbleibenden Verweise auf die vorstandardisierte Kyber-Gruppe aus Ihrer Konfiguration und Ihrem Inventar.