ML-KEM vs Kyber : ce qui a changé entre le projet et FIPS 203

CRYSTALS-Kyber et ML-KEM ne sont pas deux algorithmes distincts. ML-KEM est la forme normalisée de CRYSTALS-Kyber, publiée par le NIST sous la référence FIPS 203 le 13 août 2024. Le changement n'est pas cosmétique : FIPS 203 est une spécification qui possède ses propres noms de jeux de paramètres, ses propres formats de clés et ses propres règles de validation. Une implémentation de la soumission antérieure au concours n'est pas interopérable avec une implémentation de ML-KEM. En TLS, c'est la raison pour laquelle le groupe pré-normatif X25519Kyber768Draft00 (codepoint 0x6399) est obsolète et doit être remplacé par les groupes ML-KEM.

Une conception, deux noms, une seule spécification approuvée

Un KEM (mécanisme d'encapsulation de clé) est le composant d'une poignée de main qui permet à deux parties de s'accorder sur un secret partagé. CRYSTALS-Kyber était le nom du KEM fondé sur les réseaux euclidiens soumis au processus de normalisation post-quantique du NIST. Lorsque le NIST a publié la norme finale, l'algorithme a été renommé ML-KEM, abréviation de Module-Lattice-Based Key-Encapsulation Mechanism, et spécifié dans FIPS 203. Il a été publié le même jour que FIPS 204 (ML-DSA, signatures) et FIPS 205 (SLH-DSA, signatures sans état fondées sur le hachage).

Dans une conversation, Kyber et ML-KEM désignent la même famille de conceptions. Dans du code, dans une liste de groupes ou dans un document de conformité, ils ne sont pas interchangeables. Seul ML-KEM tel que spécifié dans FIPS 203 constitue une norme approuvée. Tout ce qui porte encore l'étiquette Kyber, Kyber768 ou Draft00 lui est antérieur. Notre page de référence ML-KEM suit la norme et son statut, et la page consacrée au projet Kyber suit les groupes pré-normatifs qu'il convient désormais de retirer des configurations.

Ce que le passage du projet à la norme finale a changé

FIPS 203 a d'abord été publiée sous forme de projet public initial soumis à commentaires, avant que le NIST n'en publie le texte final. Trois catégories de changements comptent pour un ingénieur ou un architecte.

Noms et jeux de paramètres

Kyber512, Kyber768 et Kyber1024 sont devenus ML-KEM-512, ML-KEM-768 et ML-KEM-1024. FIPS 203 spécifie exactement ces trois jeux de paramètres. Une option de compilation, une constante ou un vecteur de test qui porte encore un nom Kyber indique que le code n'a pas été mis à jour, et pas seulement que quelqu'un a conservé une ancienne étiquette.

Détails de spécification qui rompent l'interopérabilité

La norme finale diffère de la soumission antérieure au concours sur des détails de spécification, notamment la génération des clés, l'encodage des clés et la dérivation du secret partagé. Ces détails sont normatifs dans FIPS 203 et doivent être lus dans le texte plutôt que dans un résumé de seconde main. La conséquence pratique est simple et absolue : un pair utilisant Kyber pré-normatif et un pair utilisant ML-KEM ne dériveront pas le même secret partagé. Il n'existe entre eux ni négociation, ni chemin de repli, ni compatibilité partielle. La poignée de main échoue, ou le groupe n'est tout simplement jamais sélectionné.

Règles qu'une implémentation doit respecter

FIPS 203 spécifie également les vérifications qu'une implémentation effectue sur le matériel de clé reçu avant de l'utiliser, et définit le comportement de la désencapsulation lorsque l'entrée n'est pas valide (rejet implicite, qui renvoie un secret partagé pseudo-aléatoire au lieu d'une erreur). L'essentiel de cette charge repose sur les auteurs de bibliothèques. Pour l'utilisateur d'une bibliothèque, la leçon est de préférer une implémentation maintenue qui déclare sa conformité à FIPS 203 plutôt qu'une copie du code de référence de la période du concours, et de vérifier les notes de version plutôt que le nom de l'algorithme.

Les trois jeux de paramètres : 512, 768 et 1024

FIPS 203 définit les trois jeux de paramètres par rapport aux catégories de sécurité du NIST. Le nombre n'est pas une longueur de clé en bits : c'est une étiquette désignant le jeu de paramètres.

Pour le TLS et le SSH d'usage général, l'écosystème a convergé vers ML-KEM-768 au sein d'une construction hybride. Si vous exploitez des systèmes relevant de NSA CNSA 2.0, la suite désigne ML-KEM-1024 avec ML-DSA-87, LMS ou XMSS, AES-256 et SHA-384 ou SHA-512, avec un usage exclusif attendu d'ici fin 2030 pour la signature de logiciels et de micrologiciels et pour les équipements réseau traditionnels, et d'ici fin 2033 pour les navigateurs et serveurs web, les services cloud et les systèmes d'exploitation. D'autres autorités formulent leurs positions sous forme de recommandations : le BSI TR-02102-1 recommande l'échange de clés post-quantique hybride, et l'ANSSI rend l'hybridation obligatoire dans son périmètre réglementé tout en précisant que ses recommandations post-quantiques ne constituent pas encore des obligations réglementaires ailleurs. Cet article est fourni à titre d'information et ne constitue pas un conseil juridique.

Groupes TLS : ce qui est actuel, ce qui est obsolète

Le groupe nommé est la partie visible de tout cela. Seuls les codepoints ci-dessous existent dans le registre IANA pour ML-KEM, et un seul d'entre eux correspond à l'entrée pré-normative obsolète.

Les groupes hybrides combinent un échange de clés classique avec ML-KEM : la session reste au moins aussi robuste que sa partie classique si une faiblesse est découverte dans la construction à base de réseaux euclidiens, et elle gagne une protection post-quantique contre le trafic enregistré. Cette combinaison est décrite pour TLS 1.3 dans la RFC 10024 (août 2026). Le trafic enregistré n'est protégé que par l'échange de clés, c'est pourquoi l'échange de clés migre en premier et les certificats peuvent suivre plus tard. La page X25519MLKEM768 détaille le groupe que la plupart des serveurs devraient activer en premier.

Ce qu'il faut vérifier dans les bibliothèques, les serveurs et SSH

Exécutez d'abord des vérifications en lecture seule, sur un hôte de préproduction, avant de toucher à une configuration de production.

OpenSSL

OpenSSL 3.5 ou une version ultérieure est nécessaire pour les groupes TLS ML-KEM. Une branche plus ancienne peut encore annoncer un groupe issu du projet Kyber via un provider ou un correctif de distribution : c'est précisément le cas à identifier et à supprimer.

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

Dans la sortie de s_client, lisez le groupe négocié. Si la connexion échoue avec une erreur de poignée de main alors qu'un groupe classique fonctionne, le serveur ne prend pas encore en charge ML-KEM.

Configuration du serveur

Conservez toujours un repli classique après le groupe hybride afin que les clients plus anciens puissent encore se connecter. Sur nginx compilé avec OpenSSL 3.5 ou une version ultérieure :

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

La syntaxe et les valeurs prises en charge varient selon les serveurs et selon les compilations des distributions : vérifiez-les pour votre propre version. Notre guide pour activer ML-KEM sur nginx, Apache, HAProxy et Caddy présente la directive propre à chacun.

SSH

OpenSSH 9.9 (19 septembre 2024) a ajouté mlkem768x25519-sha256, disponible par défaut. OpenSSH 10.0 (9 avril 2025) en a fait l'échange de clés par défaut, et OpenSSH 10.1 (6 octobre 2025) émet un avertissement lorsqu'une connexion négocie un échange de clés qui n'est pas post-quantique, via l'option WarnWeakCrypto activée par défaut. Les versions antérieures, à partir d'OpenSSH 9.0, utilisent par défaut l'hybride sntrup761x25519-sha512@openssh.com, qui est post-quantique mais n'est pas ML-KEM.

ssh -V
ssh -Q kex | grep mlkem

Code applicatif et dépendances

• Recherchez dans vos dépôts et votre gestion de configuration les chaînes Kyber, kyber768, Draft00 et 0x6399. Chaque occurrence est soit du code mort, soit une erreur de configuration active.
• Vérifiez les listes de groupes figées dans les répartiteurs de charge, les CDN, les passerelles d'API, les reverse proxies et les terminaisons TLS. Une liste figée est la raison la plus fréquente pour laquelle une bibliothèque moderne négocie encore un groupe classique.
• Vérifiez dans les notes de version de votre bibliothèque cryptographique, et non dans le nom de l'algorithme, la mention indiquant que l'implémentation suit FIPS 203. Lorsque la validation FIPS vous importe, vérifiez le statut de validation du module et de la version précis que vous livrez.
• Consignez le jeu de paramètres, et pas seulement l'algorithme, dans votre inventaire : ML-KEM-768 et ML-KEM-1024 sont deux réponses différentes pour un auditeur qui vous demande lequel vous avez déployé.

Vérifiez ce que vos serveurs négocient réellement

Le moyen le plus rapide de savoir si un domaine utilise la norme ou encore un groupe issu d'un projet est d'observer ce qu'il propose sur le réseau. Vous pouvez analyser votre domaine avec PQC Status gratuitement : l'outil indique les groupes ML-KEM hybrides qu'un serveur accepte, les versions de TLS et les suites de chiffrement, ainsi que la chaîne de certificats. Une analyse décrit uniquement la configuration TLS visible de l'extérieur. Elle ne constitue ni une certification ni une attestation de conformité. L'étape suivante concrète sur ce sujet : confirmez que chaque point de terminaison public propose X25519MLKEM768 avec un repli classique, puis supprimez toute référence restante au groupe Kyber pré-normatif de votre configuration et de votre inventaire.