Pourquoi ML-KEM-1024 est le nouveau standard pour les communications sécurisées

Pendant cinquante ans, la cryptographie asymétrique a reposé sur deux hypothèses mathématiques : la difficulté de factoriser de grands entiers et l'intractabilité du problème du logarithme discret sur les courbes elliptiques. RSA, Diffie-Hellman et ECDH ont protégé tout, des handshakes TLS aux liaisons de commandement et de contrôle militaires, avec des marges de sécurité qui ont crû avec la taille des clés.

L'algorithme de Shor, décrit pour la première fois en 1994, a brisé ce paradigme sur le plan théorique. Un calculateur quantique tolérant aux fautes de taille suffisante résoudrait les deux problèmes en temps polynomial, réduisant RSA à 3072 bits et ECC P-256 à des secrets trivialement récupérables. Ce qui a maintenu le calme dans la communauté de sécurité a été l'écart d'ingénierie entre l'algorithme théorique et la machine pratique. Cet écart se réduit plus rapidement que la plupart des défenseurs ne sont prêts à l'admettre.

Les progrès récents sur la correction d'erreur des qubits logiques, les codes de surface et la compilation dynamique des circuits ont rapproché les estimations les plus crédibles du Q-Day vers une fenêtre centrée sur la prochaine décennie. Pour toute donnée qui doit rester confidentielle au-delà de cette fenêtre, la menace n'est pas hypothétique : elle est déjà présente sous la forme du harvest-now decrypt-later, à savoir l'archivage aujourd'hui du trafic chiffré pour le déchiffrer une fois que le matériel sera disponible [4][11].

ML-KEM est l'acronyme de Module-Lattice-Based Key-Encapsulation Mechanism. Il s'agit d'un schéma d'encapsulation de clé, et non d'une signature numérique : sa fonction est de permettre à deux parties de s'accorder sur un secret symétrique au travers d'un canal non fiable. Le problème difficile sous-jacent est Module-LWE, une variante structurée de Learning With Errors sur des anneaux polynomiaux, pour laquelle aucun algorithme quantique sub-exponentiel n'est connu à ce jour [5].

La FIPS 203 spécifie trois jeux de paramètres [1]. ML-KEM-512 vise la catégorie de sécurité NIST 1 (équivalente approximativement à AES-128). ML-KEM-768 vise la catégorie 3 (AES-192). ML-KEM-1024 vise la catégorie 5 (AES-256). Les différences résident dans les dimensions du réseau et les paramètres de bruit, et non dans la structure algorithmique. Les primitives d'encapsulation, de décapsulation et de génération de clés sont identiques dans les trois cas.

Le coût en termes de taille est modéré mais non négligeable. Une clé publique ML-KEM-1024 occupe 1568 octets, un ciphertext 1568 octets, une clé secrète 3168 octets. Comparés aux 32 octets d'une clé publique X25519, on parle d'une augmentation d'environ 49 fois. Pour un handshake TLS, cela représente quelques kilo-octets supplémentaires par session. Pour la plupart des applications, c'est sans conséquence. Pour les liaisons radio contraintes, cela exige une attention d'ingénierie [6].

La question pragmatique pour tout architecte système est celle du jeu de paramètres à adopter. Le NIST accepte ML-KEM-768 comme choix par défaut pour la majeure partie de l'usage fédéral. La NSA, via la directive CNSA 2.0, impose ML-KEM-1024 pour tous les National Security Systems et pour toute donnée classée Secret ou au-delà [4]. La directive technique TR-02102-1 du BSI allemand recommande pareillement des paramètres de catégorie 5 pour toute donnée dont l'horizon de protection dépasse dix ans [9].

L'argument en faveur de ML-KEM-1024 n'est pas que ML-KEM-768 serait compromis. C'est que la marge de sécurité face aux futures avancées de la cryptanalyse est sensiblement plus large. La cryptanalyse sur réseaux est un domaine actif et plusieurs travaux récents ont affiné les modèles de coût de la famille d'algorithmes de réduction BKZ. Chaque raffinement a érodé de quelques bits le niveau de sécurité conjecturé pour ML-KEM-768. Aucun n'a en revanche entamé la marge de ML-KEM-1024.

Pour les communications souveraines, les applications militaires et les secrets industriels de longue durée, le cas est net. La différence de performance entre catégorie 3 et catégorie 5 est de l'ordre de 30 à 40 % en cycles CPU, ce qui pour un échange de clé qui survient une fois par session est opérationnellement invisible. La différence de bande passante est analogue. Il n'existe aucune raison défendable de choisir le paramètre le plus petit lorsque l'on protège une donnée avec une exigence de confidentialité pluri-décennale.

Toutes les lignes directrices crédibles de déploiement, depuis le NIST SP 800-227 [10] jusqu'aux travaux de l'ETSI sur les mécanismes hybrides en passant par le BSI allemand [9], recommandent l'établissement de clé hybride pendant la phase de transition. Un schéma hybride combine une primitive classique (typiquement X25519 ou ECDH P-384) avec ML-KEM-1024, dérivant la clé de session finale à partir des deux secrets partagés au travers d'une KDF telle que HKDF-SHA384.

Le raisonnement est prudentiel. ML-KEM est jeune. Il a survécu à quatre tours d'analyse publique dans le cadre du processus PQC du NIST [3], mais la communauté cryptanalytique a eu moins d'une décennie pour étudier sa version définitive. Un défaut subtil dans la formulation sur réseaux, dans l'échantillonnage du bruit ou dans l'implémentation pourrait en principe réduire sa sécurité effective. La primitive classique constitue le filet de sécurité : tant qu'au moins un des deux problèmes sous-jacents reste difficile, la clé de session reste irrécupérable.

Le coût de l'hybride est une multiplication scalaire supplémentaire et un appel à la KDF, soit pratiquement rien. Le coût en complexité est réel et c'est là que la plupart des projets trébuchent. Les entrées de la KDF doivent être ordonnées correctement. L'encodage de la longueur doit être non ambigu. La défaillance d'un composant ne doit pas laisser fuir de l'information sur l'autre. Les drafts IETF sur l'hybride, en particulier draft-ietf-tls-hybrid-design [7], capturent le consensus sur ces détails.

ML-KEM est structurellement simple mais opérationnellement intolérant. La transformation de Fujisaki-Okamoto utilisée pour obtenir la sécurité IND-CCA2 repose sur une vérification de re-chiffrement à l'intérieur du décapsulement. Les implémentations qui branchent sur le résultat de cette vérification, ou qui laissent fuir de l'information temporelle à son sujet, deviennent vulnérables à des attaques à ciphertext choisi capables de récupérer la clé secrète de long terme en quelques minutes. L'implémentation constant-time n'est pas une recommandation, c'est une exigence.

L'arithmétique polynomiale sur l'anneau Z_q[x]/(x^256 + 1) avec q = 3329 est typiquement accélérée par la Number Theoretic Transform. Les implémentations de la NTT qui utilisent des réductions modulaires non constant-time, ou qui présentent des fuites de cache timing, ont été cassées dans des attaques side-channel publiées [6]. Les implémentations matérielles sur FPGA et accélérateurs dédiés ont démontré des NTT pleinement constant-time, mais les déploiements purement logiciels sur CPU généraliste exigent un codage soigneux et une vérification régulière avec des outils tels que ctgrind ou dudect.

La génération de nombres aléatoires pour l'échantillonnage du bruit est un autre point de rupture. L'implémentation de référence utilise SHAKE-128 ensemencé par un secret de 32 octets. Toute réduction de l'entropie de cette semence compromet l'ensemble du schéma. La seule configuration de production acceptable est l'entropie matérielle issue d'un TRNG certifié, couplée à un DRBG conforme à NIST SP 800-90A.

L'étude d'intégration de l'ENISA sur la cryptographie post-quantique définit le socle européen de la migration [8]. Les États membres le traduisent désormais en mandats nationaux : le BSI allemand a aligné son catalogue cryptographique autour de ML-KEM-1024 et ML-DSA-87 [9], et l'ANSSI française a émis des positions techniques qui exigent la PQC hybride pour les produits qualifiés.

Pour les fournisseurs qui vendent dans les infrastructures critiques européennes, dans la défense, dans les télécommunications ou dans la finance, l'implication opérationnelle est concrète. Tout produit dont le cycle de vie certifié s'étend au-delà de 2030 doit déjà inclure un chemin de migration PQC. Tout produit qui arrive sur le marché à partir de 2026, s'il prétend adresser des cas d'usage à longue confidentialité, doit être livré avec la PQC activée par défaut. Vos clients vous demanderont de plus en plus souvent non pas si vous supportez la PQC, mais quel jeu de paramètres vous expédiez et comment votre hybride est construit [7].

Si vous opérez ou construisez des systèmes qui protègent des données avec une fenêtre de confidentialité supérieure à cinq ans, ML-KEM-1024 en mode hybride est le nouveau socle de référence. Adopter ML-KEM-768 par défaut pour économiser quelques kilo-octets est une fausse économie : vous reconstruirez le même système dans trois ans sous pression réglementaire, à un coût sensiblement plus élevé.

Premiers pas pratiques : inventorier chaque point de votre stack où apparaissent RSA, ECDH ou DH. Identifier lesquels touchent des données soumises à une exigence de longue confidentialité. Interroger vos fournisseurs de TLS, de VPN et de HSM sur leurs feuilles de route PQC et exiger ML-KEM-1024 hybride avec X25519. Pour les protocoles propriétaires, suivez les drafts IETF sur l'hybride au lieu d'assembler des compositions maison [7].

La transition ne sera pas bon marché, mais l'alternative est pire. La donnée exfiltrée aujourd'hui et déchiffrée en 2032 n'est pas un risque hypothétique : c'est la thèse opérationnelle explicite de chaque agence étatique de signals intelligence de la planète. ML-KEM-1024 est la réponse prudente, défendable et alignée avec le régulateur à cette thèse. C'est le nouveau standard parce qu'il n'existe plus de raison crédible de choisir quelque chose de plus faible [1][4][9].