Gestion des clés ML-KEM : générer, stocker et renouveler les clés post-quantiques (2026)

La gestion des clés ML-KEM est l'ensemble des contrôles qui encadrent la génération, le stockage, la distribution, la rotation et la destruction des clés utilisées par ML-KEM, le mécanisme d'encapsulation de clés post-quantique normalisé par le NIST dans FIPS 203. La plupart des clés ML-KEM sont éphémères et ne vivent que le temps d'une poignée de main TLS ; les clés statiques exigent la même protection que toute clé privée à long terme, avec deux particularités : des clés plus grandes, et une graine (seed) de 64 octets aussi sensible que la clé privée elle-même.

L'établissement de clés est la partie de votre cryptographie exposée au « harvest now, decrypt later » : un trafic enregistré aujourd'hui avec un échange de clés RSA ou ECDH pourra être déchiffré dès qu'un ordinateur quantique suffisamment puissant existera. C'est pourquoi le projet de plan de transition du NIST et le calendrier fédéral américain placent l'établissement de clés en premier, et pourquoi ML-KEM est le premier algorithme post-quantique que la plupart des organisations exploiteront en production, souvent déjà via le TLS hybride des versions récentes d'OpenSSL.

Ce guide couvre les tailles de clés de FIPS 203, les différences entre la gestion des clés ML-KEM et celle de RSA et d'ECDH, le TLS hybride avec X25519MLKEM768, l'emplacement des clés ML-KEM, un tableau du cycle de vie, les échéances de NIST IR 8547 et de CNSA 2.0, la gestion des clés PQC au sens large (ML-DSA, SLH-DSA et hiérarchie de clés), ainsi que la planification de la migration.

---

Table des matières

1. Qu'est-ce que ML-KEM ?
2. Jeux de paramètres et tailles de clés ML-KEM
3. Pourquoi la gestion des clés ML-KEM diffère de RSA et d'ECDH
4. Comparaison : gestion des clés RSA et ECDH vs ML-KEM
5. TLS post-quantique hybride et X25519MLKEM768
6. Où vivent les clés ML-KEM : éphémères ou statiques
7. Le cycle de vie des clés ML-KEM
8. Échéances : NIST IR 8547 et CNSA 2.0
9. Gestion des clés PQC : au-delà de ML-KEM
10. Comment planifier votre migration vers ML-KEM
11. Le rôle de DuoKey
12. FAQ

---

Qu'est-ce que ML-KEM ?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) est spécifié dans FIPS 203, publié par le NIST le 13 août 2024. Selon les termes du NIST, il s'agit d'un mécanisme d'encapsulation de clés que deux parties peuvent utiliser « to establish a shared secret key over a public channel » (pour établir une clé secrète partagée sur un canal public). Sa sécurité repose sur le problème Module Learning with Errors, réputé résister aux attaques par ordinateur quantique.

Deux points comptent pour la gestion des clés :

• ML-KEM est un KEM, pas un schéma de signature. Il remplace le transport de clés RSA et l'accord de clés (EC)DH. Il ne signe rien. Les certificats, la signature de code et l'authentification migrent vers ML-DSA (FIPS 204) ou SLH-DSA (FIPS 205), traités dans notre guide sur les certificats ML-DSA et la PKI post-quantique.
• Un KEM compte trois opérations, pas deux. KeyGen produit une clé d'encapsulation ek (publique) et une clé de décapsulation dk (privée). Encaps(ek) renvoie un chiffré et un secret partagé de 32 octets. Decaps(dk, ciphertext) retrouve le même secret partagé.

ML-KEM en bref

ML-KEM ou Kyber. ML-KEM n'est pas identique octet pour octet à la soumission CRYSTALS-Kyber. La FAQ CNSA 2.0 de la NSA rappelle que les algorithmes CRYSTALS ont connu plusieurs versions, avec des ajustements faits avant la publication de la FIPS. Les implémentations de Kyber pré-normatif, comme l'ancien groupe TLS X25519Kyber768Draft00, n'interopèrent pas avec ML-KEM et doivent être mises à jour.

ML-KEM est l'une des trois normes post-quantiques du NIST, avec ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) ; notre présentation de la cryptographie post-quantique (en anglais) les compare.

La recommandation complémentaire du NIST, SP 800-227 (version finale, septembre 2025), explique comment utiliser les KEM en toute sécurité, notamment les clés statiques et éphémères, les données au repos et les constructions hybrides. Lisez-la en parallèle de FIPS 203 lorsque vous rédigez une politique ML-KEM.

---

Jeux de paramètres et tailles de clés ML-KEM

FIPS 203 approuve trois jeux de paramètres. Les tailles ci-dessous proviennent du tableau 3 de FIPS 203 ; les catégories de sécurité, de la section 8.

À titre de comparaison, une clé publique X25519 fait 32 octets.

Lequel choisir. FIPS 203 indique : « NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost. » (Le NIST recommande ML-KEM-768 comme jeu de paramètres par défaut, car il offre une large marge de sécurité pour un coût de performance raisonnable.) La norme conseille aussi d'utiliser le jeu de paramètres le plus robuste qui soit praticable dès la mise en place de la protection, afin d'éviter une transition ultérieure. Les systèmes de sécurité nationale suivent CNSA 2.0, qui désigne ML-KEM-1024 (voir Échéances).

La graine. La génération de clés ML-KEM part de deux valeurs aléatoires de 32 octets, d et z. FIPS 203 autorise le stockage de cette graine de 64 octets pour redériver la paire de clés plus tard, mais précise que « it is sensitive data and shall be treated with the same safeguards as a decapsulation key » (il s'agit de données sensibles, qui doivent bénéficier des mêmes protections qu'une clé de décapsulation).

---

Pourquoi la gestion des clés ML-KEM diffère de RSA et d'ECDH

1. Une interface différente. Avec ECDH, chaque partie combine sa clé privée avec la clé publique de l'autre. Avec le transport de clés RSA, l'émetteur choisit un secret et le chiffre. ML-KEM ne fait ni l'un ni l'autre : la partie qui encapsule obtient un nouveau secret partagé et un chiffré, et seul le détenteur de dk peut retrouver ce secret. Les bibliothèques, les API de HSM et les workflows d'encapsulation (key wrapping) construits autour de encrypt/decrypt ou de derive ont besoin d'un nouveau chemin encapsulate/decapsulate. PKCS#11 3.2 ajoute précisément cela (voir la FAQ).

2. Les clés éphémères et statiques obéissent à des règles différentes. SP 800-227 est explicite : « If an application uses an ephemeral key pair, the key pair shall be used for only one execution of key-establishment via a KEM and shall be destroyed as soon as possible after its use. » (Si une application utilise une paire de clés éphémère, celle-ci ne doit servir qu'à une seule exécution d'établissement de clés via un KEM et doit être détruite le plus tôt possible après usage.) Une clé ML-KEM statique, en revanche, est une clé privée à long terme qui exige garde, sauvegarde et rotation.

3. Deux formats privés à gérer. Une clé privée ML-KEM peut être stockée sous forme de graine de 64 octets, de dk étendue (1 632 à 3 168 octets), ou des deux. SP 800-227 note que « some applications might call for storing keys using only a short seed, while other applications might call for storing keys in an expanded format that allows for faster computations » (certaines applications peuvent exiger de stocker les clés sous la seule forme d'une graine courte, d'autres sous un format étendu qui accélère les calculs). Votre politique doit préciser quel format est stocké, exporté et sauvegardé, car une sauvegarde contenant uniquement la graine ne peut pas être restaurée dans un système qui n'accepte que dk, et inversement.

4. La preuve de possession change. Une clé KEM ne peut pas signer une demande de certificat. SP 800-227 précise qu'une partie qui utilise la clé d'encapsulation statique d'une autre « must have assurance of the other party's ownership of the key » (doit avoir l'assurance que l'autre partie détient bien la clé), assurance obtenue auprès d'une autorité de certification ou par une preuve de possession associée à une vérification d'identité. Attendez-vous à ce que les processus d'enrôlement des certificats ML-KEM diffèrent du modèle CSR signée que vous utilisez pour RSA.

5. La vérification des entrées est obligatoire. FIPS 203 exige que Encaps et Decaps ne s'exécutent que sur des entrées vérifiées (section 7). Importer une clé provenant d'une source non fiable est donc une étape de validation, pas une simple copie de fichier.

6. Des objets plus volumineux. Des clés et des chiffrés plus grands ont un impact sur les poignées de main TLS, les colonnes de base de données, les limites d'attributs et les quotas de stockage des HSM.

---

Comparaison : gestion des clés RSA et ECDH vs ML-KEM

---

TLS post-quantique hybride et X25519MLKEM768

X25519MLKEM768 est un groupe d'échange de clés TLS 1.3 qui exécute ML-KEM-768 et X25519 en parallèle et combine les deux secrets partagés, de sorte que la session reste sûre tant que l'un des deux algorithmes tient. Il est normalisé dans la RFC 10024, « Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 » (Standards Track, août 2026), publiée à partir du brouillon IETF draft-ietf-tls-ecdhe-mlkem.

La RFC 10024 définit trois groupes :

Un détail piège les implémenteurs : dans X25519MLKEM768, la partie ML-KEM vient en premier dans le partage de clé et dans le secret partagé concaténé, alors que les deux groupes à courbes NIST placent la partie ECDH en premier.

Ce que cela implique pour la gestion des clés : rien à stocker. Dans le TLS 1.3 hybride, le client génère une nouvelle paire de clés ML-KEM à chaque poignée de main, envoie la clé d'encapsulation de 1 184 octets, et le serveur répond par un chiffré. Les deux paires de clés sont éphémères et détruites après la poignée de main, exactement comme ECDHE aujourd'hui. Le serveur continue de s'authentifier avec son certificat RSA ou ECDSA existant.

Ce groupe est aussi déjà déployé. La prise en charge par les navigateurs et serveurs, les points de vigilance et des exemples de configuration figurent dans notre guide du TLS post-quantique hybride (en anglais). OpenSSL 3.5.0 (8 avril 2025) a ajouté ML-KEM, ML-DSA et SLH-DSA et a modifié « the default TLS keyshares ... to offer X25519MLKEM768 and X25519 » (les partages de clés TLS par défaut, pour proposer X25519MLKEM768 et X25519). Pour vérifier si un serveur le négocie :

# OpenSSL 3.5 or later
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i -E "group|temp key"

---

Où vivent les clés ML-KEM : éphémères ou statiques

La première décision consiste à déterminer quelles clés doivent réellement être gérées.

Pour les clés statiques, SP 800-227 fixe le socle : les données privées (graines et clés de décapsulation) « needs to be stored within the cryptographic module in a manner that is secure against both leakage and unauthorized modification » (doivent être stockées dans le module cryptographique de manière à être protégées contre les fuites comme contre les modifications non autorisées), et l'import comme l'export « needs to be performed in a secure manner » (doivent être réalisés de manière sécurisée). En pratique : générer dans le KMS ou le HSM, garder dk non exportable sauf si la sauvegarde impose un export encapsulé, et n'exposer que Decaps aux applications.

---

Le cycle de vie des clés ML-KEM

Utilisez ce tableau comme point de départ d'une politique de clés ML-KEM statiques. Les clés TLS éphémères ne concernent que les lignes génération et destruction, prises en charge par la bibliothèque TLS.

Si vous avez besoin d'un fichier de clé portable pour des tests, OpenSSL 3.5 montre directement le choix de la graine. Par défaut, il conserve la graine ; cette commande n'écrit que la dk FIPS 203 :

openssl genpkey -provparam ml-kem.retain_seed=no -algorithm ml-kem-768 -out priv-only.pem

Réservez ces clés logicielles aux tests.

---

Échéances : NIST IR 8547 et CNSA 2.0

NIST IR 8547. Le document du NIST Transition to Post-Quantum Cryptography Standards n'est encore qu'un projet initial soumis à consultation publique (publié le 12 novembre 2024 ; consultation close le 10 janvier 2025). Pour l'établissement de clés, il propose que DH/MQV sur corps finis, DH/MQV sur courbes elliptiques et l'établissement de clés RSA à 112 bits de sécurité soient dépréciés après 2030, et que ces algorithmes à 112 bits et à 128 bits ou plus soient interdits après 2035. S'agissant d'un projet, ces dates indiquent l'orientation du NIST plutôt que des règles définitives.

CNSA 2.0. Aux États-Unis, les systèmes de sécurité nationale suivent la suite CNSA 2.0 de la NSA. Un Internet-Draft de l'IETF rédigé par la NSA, qui définit un profil TLS pour CNSA 2.0 (draft-becker-cnsa2-tls-profile), indique que « CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS » (CNSA 2.0 exige ML-KEM-1024 pour l'établissement de clés dans TLS). La FAQ CNSA 2.0 de la NSA retient ML-KEM-1024 pour tous les niveaux de classification. Les algorithmes CNSA 2.0 sont exigés dans les nouvelles acquisitions de systèmes de sécurité nationale à partir du 1er janvier 2027 et obligatoires d'ici le 31 décembre 2031 ; voir le calendrier CNSA 2.0 (en anglais). L'articulation avec le calendrier fédéral civil de l'OMB figure dans notre guide de la réglementation post-quantique américaine : NIST, OMB et CNSA 2.0.

---

Gestion des clés PQC : au-delà de ML-KEM

La gestion des clés PQC applique les contrôles du cycle de vie des clés (génération, stockage, distribution, rotation, sauvegarde, destruction et audit) aux clés post-quantiques et à la hiérarchie de clés qui les protège. ML-KEM n'en est qu'une partie. Une politique complète de gestion des clés post-quantiques couvre aussi les clés de signature et les clés au sommet de votre hiérarchie.

Les trois types de clés post-quantiques du NIST

Les tailles proviennent de FIPS 203, FIPS 204 (tableau 2, ML-DSA-44/65/87) et FIPS 205. Les signatures à base de hachage avec état (LMS et XMSS, NIST SP 800-208) ajoutent une règle : le signataire ne doit jamais réutiliser une clé à usage unique, l'état doit donc être sauvegardé et synchronisé avec le plus grand soin. Les clés symétriques ne posent pas problème : AES-256 reste acceptable, et CNSA 2.0 l'exige.

Commencer par la racine de la hiérarchie de clés

Une clé post-quantique protégée par une clé parente classique n'est pas plus solide que cette parente. Si une clé RSA enveloppe vos clés de chiffrement de clés (KEK), ou si une clé est exportée sous RSA-OAEP, une copie enregistrée de cet échange est exposée au « harvest now, decrypt later », même si toutes les clés de données en dessous résistent au quantique. En pratique :

• Les hiérarchies symétriques (clés maîtres et KEK AES-256 dans un HSM) n'ont pas besoin d'un nouvel algorithme. Vérifiez plutôt comment les clés entrent dans la hiérarchie et en sortent.
• L'enveloppement et le transport asymétriques (transport de clés RSA, enveloppement basé sur ECDH, imports BYOK) doivent passer à ML-KEM ou à un enveloppement symétrique selon un plan daté.
• Les clés de CA racine et émettrices passent en premier à ML-DSA ou SLH-DSA dans votre plan de signatures, car chaque certificat en dessous hérite de leur algorithme. Voir le guide des certificats ML-DSA et de la PKI post-quantique.

Que demander à vos fournisseurs de KMS et de HSM

En pratique, la gestion des clés post-quantiques échoue là où un magasin de clés ne sait pas stocker les nouveaux objets. Pour chaque HSM, KMS cloud et gestionnaire de secrets, demandez des réponses datées sur :

1. La génération de clés ML-KEM, ML-DSA et SLH-DSA dans le module, et les jeux de paramètres pris en charge.
2. Le support des API : mécanismes PKCS#11 3.2, KMIP ou API propriétaire, y compris l'encapsulation et la décapsulation pour ML-KEM.
3. Les formats d'export et de sauvegarde (graine ou clé développée, encodages IETF LAMPS) et la possibilité de restaurer une sauvegarde dans le module d'un autre fournisseur.
4. Le statut de validation (certificats FIPS 140-3 qui listent les algorithmes post-quantiques).
5. Le support hybride : le magasin peut-il détenir une clé classique et une clé post-quantique sous une même politique pendant la transition ?

Consignez les réponses dans votre inventaire cryptographique pour que la feuille de route de migration PQC puisse planifier chaque magasin de clés.

---

Comment planifier votre migration vers ML-KEM

1. L'inventaire d'abord. Identifiez où se produit l'établissement de clés RSA et ECDH : points de terminaison TLS, VPN, clés d'encapsulation, clés de KMS et de HSM, code. Commencez par un inventaire cryptographique et tenez-le à jour sous forme de CBOM (cryptography bill of materials).
2. Séparez l'éphémère du statique. L'échange de clés éphémère TLS et VPN relève d'un projet de mise à niveau (bibliothèques, répartiteurs de charge, équipements intermédiaires qui doivent gérer des poignées de main plus volumineuses). Les clés KEM statiques relèvent d'un projet de gestion des clés.
3. Activez l'hybride là où c'est possible. Activez X25519MLKEM768 sur les points de terminaison que vous contrôlez et mesurez à quelle fréquence il est négocié. Les certificats restent inchangés.
4. Vérifiez vos magasins de clés. Demandez à chaque fournisseur de HSM, de KMS et de gestionnaire de secrets un support daté des objets de clés ML-KEM, des opérations d'encapsulation/décapsulation, du stockage graine ou dk et de l'export encapsulé.
5. Rédigez la politique. Jeu de paramètres, format de stockage, cryptopériode, format de sauvegarde, destruction, et qui peut décapsuler. Appuyez-vous sur le tableau du cycle de vie ci-dessus.
6. Faites de l'algorithme une décision de politique. Des algorithmes codés en dur transforment chaque changement en nouvelle version logicielle ; une plateforme de crypto-agilité déplace ce choix vers une politique centrale.
7. Mesurez en continu. La gestion de la posture cryptographique maintient l'inventaire à jour et suit la remédiation ; une feuille de route de migration PQC relie le tout à des dates et à des responsables.

---

Le rôle de DuoKey

DuoKey couvre les étapes d'inventaire et de politique ci-dessus. D'après la documentation de DuoKey :

• Découverte. Le PQC Scanner de DuoKey, moteur de découverte de DuoKey CPM, trouve les certificats et les clés sur les systèmes de fichiers, les keystores et les KMS cloud (AWS, Azure, GCP), et son Domain Scanner peut détecter l'échange de clés post-quantique. Il signale RSA et ECDSA comme vulnérables au quantique, liste ML-KEM à titre informatif, et produit un CBOM et un Quantum Readiness Score. Vous pouvez commencer par le Quantum Readiness Score gratuit, qui ne nécessite aucun accès aux systèmes internes.
• Une politique plutôt que des algorithmes codés en dur. Avec le Crypto Agility Plane (CAP), les développeurs déclarent une classe de données et une finalité plutôt qu'un algorithme. Une politique centrale par tenant détermine à l'exécution l'algorithme, la posture post-quantique (classical, hybrid ou pqc_only), la référence de clé et le backend. La posture hybride avec ML-KEM et ML-DSA est disponible d'emblée. Passer au PQC seul est une modification de politique ; le code applicatif ne change pas.
• Les clés restent dans vos backends. CAP ne détient aucun matériel de clé. Il accède aux backends via PKCS#11 et KMIP, notamment les HSM Securosys, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault et OpenBao. Le MPC est un backend de coffre optionnel pour une garde des clés à seuil, où aucun hôte ne détient une clé complète. Le stockage natif des clés ML-KEM dépend du support propre à chaque backend.
• Une console et une piste d'audit uniques. DuoKey Cockpit fournit RBAC et ABAC, l'isolation des tenants et un journal d'audit chaîné cryptographiquement.
• Les clés post-quantiques dans le coffre. Les clés post-quantiques et hybrides sont générées et utilisées dans un coffre qui les prend en charge (le Software Vault de DuoKey ou un HSM Securosys). Cockpit exporte les clés privées ML-KEM, ML-DSA et SLH-DSA dans les encodages IETF LAMPS que lit OpenSSL 3.5, ce qui rend les sauvegardes portables.

CAP fonctionne aujourd'hui sur DuoKey Cockpit via une API REST et des clients de référence Java/Spring Boot et .NET/EF Core ; des SDK packagés figurent sur la feuille de route. Pour tout ce qui n'est pas mentionné ici, par exemple le support ML-KEM d'un modèle de HSM précis, contactez DuoKey.

---

FAQ

Q: Qu'est-ce que la gestion des clés ML-KEM ?

C'est l'ensemble des contrôles qui encadrent la génération, le stockage, la distribution, la rotation, la sauvegarde et la destruction des clés ML-KEM, les clés KEM post-quantiques définies dans FIPS 203. Les clés éphémères utilisées dans le TLS hybride ne demandent qu'une configuration correcte ; les clés statiques exigent une gestion complète du cycle de vie dans un KMS ou un HSM, y compris la protection de la graine de 64 octets.

Q: Qu'est-ce que la gestion des clés PQC ?

La gestion des clés PQC est la gestion du cycle de vie des clés post-quantiques (ML-KEM pour l'établissement de clés, ML-DSA et SLH-DSA pour les signatures) et de la hiérarchie de clés au-dessus d'elles. Elle couvre l'endroit où les clés sont générées et stockées, les formats sauvegardés, le remplacement des clés d'enveloppement classiques et les produits KMS et HSM qui prennent en charge les nouveaux algorithmes. Voir Gestion des clés PQC : au-delà de ML-KEM.

Q: Qu'est-ce que ML-KEM ?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) est le mécanisme post-quantique d'encapsulation de clés normalisé par le NIST dans FIPS 203, le 13 août 2024. Deux parties l'utilisent pour convenir d'un secret partagé de 32 octets sur un canal public. Il existe en trois jeux de paramètres, ML-KEM-512, -768 et -1024 ; ML-KEM-768 est le défaut recommandé par le NIST.

Q: ML-KEM est-il identique à Kyber ?

ML-KEM est la version normalisée de CRYSTALS-Kyber, mais les deux ne sont pas identiques : l'algorithme a été ajusté avant la publication de FIPS 203. Les implémentations de Kyber pré-normatif n'interopèrent pas avec ML-KEM.

Q: ML-KEM est-il approuvé pour CNSA 2.0 ?

Oui, avec le jeu de paramètres ML-KEM-1024, que la NSA exige pour tous les niveaux de classification des systèmes de sécurité nationale. ML-KEM-512 et ML-KEM-768 sont approuvés par le NIST mais ne sont pas le choix CNSA 2.0.

Q: ML-KEM remplace-t-il RSA ?

En partie. ML-KEM remplace RSA (et ECDH) pour l'établissement de clés : transport de clés et accord de clés. Il ne remplace pas les signatures RSA ; pour celles-ci, le NIST a normalisé ML-DSA (FIPS 204) et SLH-DSA (FIPS 205). Pendant la transition, ML-KEM est généralement combiné avec X25519 ou ECDH dans un mode hybride.

Q: Qu'est-ce que X25519MLKEM768 ?

Un groupe d'échange de clés TLS 1.3 hybride qui combine ML-KEM-768 et X25519, normalisé dans la RFC 10024 avec le code point 0x11EC. Le partage client fait 1 216 octets, le partage serveur 1 120 octets, et le secret partagé combiné 64 octets. OpenSSL 3.5 le propose par défaut.

Q: Un HSM peut-il stocker des clés ML-KEM ?

Cela dépend du HSM et de son firmware. La norme PKCS#11 3.2 (OASIS Standard, juin 2026) définit les objets de clés ML-KEM (CKK_ML_KEM), un mécanisme de génération de paires de clés (CKM_ML_KEM_KEY_PAIR_GEN), C_EncapsulateKey et C_DecapsulateKey, ainsi que des attributs pour la graine (CKA_SEED) et la clé de décapsulation (CKA_VALUE). Savoir si un HSM donné les implémente, et avec quel statut de validation, est une question à poser à son fournisseur.

Q: Faut-il stocker la graine ML-KEM ou la clé de décapsulation ?

Les deux sont autorisés. FIPS 203 permet de stocker la graine de 64 octets et de redériver la paire de clés, à condition que la graine bénéficie des mêmes protections que la clé de décapsulation. Choisissez un format de référence unique par système, et assurez-vous que votre format de sauvegarde peut être importé là où vous le restaureriez.

Q: Quel jeu de paramètres ML-KEM utiliser ?

Le NIST recommande ML-KEM-768 par défaut et conseille le jeu de paramètres le plus robuste qui soit praticable. Utilisez ML-KEM-1024 lorsque CNSA 2.0 s'applique ou que votre politique exige la catégorie de sécurité 5.

Q: Faut-il de nouveaux certificats pour utiliser ML-KEM dans TLS ?

Pas pour l'échange de clés hybride. X25519MLKEM768 modifie l'échange de clés, pas l'authentification ; vos certificats RSA ou ECDSA existants continuent donc de fonctionner. Les certificats changent lorsque vous migrez les signatures vers ML-DSA.

---

Conclusion : checklist de gestion des clés ML-KEM

ML-KEM change moins de choses à la gestion des clés que ne le laissent penser ses tailles de clés, à condition de séparer les deux cas. Les clés éphémères du TLS hybride relèvent d'une tâche de configuration que vous pouvez lancer dès ce trimestre. Les clés statiques exigent une politique qui couvre la graine, l'interface KEM et la preuve de possession.

• Un inventaire montre où l'établissement de clés RSA et ECDH est utilisé
• X25519MLKEM768 est activé et surveillé sur les points de terminaison que vous contrôlez
• Les cas d'usage ML-KEM statiques sont recensés, chacun avec un responsable
• Chaque KMS et HSM dispose d'un support daté des clés ML-KEM et de l'encapsulation/décapsulation
• La politique précise le jeu de paramètres, le format de stockage (graine, dk ou les deux), la cryptopériode, la sauvegarde et la destruction
• Les graines sont protégées par les mêmes contrôles que les clés de décapsulation
• Le choix de l'algorithme est piloté par la politique, et non codé en dur dans les applications
• Les dates de migration suivent NIST IR 8547 et, le cas échéant, CNSA 2.0

---

Références

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms
• NSA: CNSA 2.0 and Quantum Computing FAQ (Ver. 2.2, octobre 2026, PDF)
• NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards
• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
• IETF Datatracker: draft-ietf-tls-ecdhe-mlkem
• OASIS PKCS #11 Specification Version 3.2
• IETF Internet-Draft: CNSA 2.0 TLS profile (draft-becker-cnsa2-tls-profile-05)
• OpenSSL 3.5 release notes
• OpenSSL 3.5: EVP_PKEY-ML-KEM
• DuoKey Docs: Crypto Agility Plane SDK
• DuoKey Docs: PQC Scanner
• DuoKey Docs: Key Export in Standard Formats
• NIST FIPS 204
• NIST FIPS 205
• NIST SP 800-208
• Cloud Security Alliance: Post-Quantum Key Management Starts at the Root