ML-KEM-768 vs ML-KEM-1024 vs NTRU Prime : 2026

Trois mécanismes d’échange de clés post-quantiques se disputent aujourd’hui les connexions SSH, les messages Signal et le trafic TLS qui protège la moitié d’Internet. NTRU Prime a ouvert la voie dans OpenSSH dès 2021. ML-KEM-768 l’a détrôné en 2025 comme nouveau standard par défaut. ML-KEM-1024 reste la variante que choisissent les applications qui refusent de transiger sur la marge de sécurité. Entre les trois, l’écart de taille dépasse 1,4 Ko sur la clé privée, et ce chiffre a des conséquences bien réelles sur la bande passante, la latence et le coût d’infrastructure à l’échelle d’un fournisseur cloud. Ce comparatif détaille les spécifications officielles, les benchmarks publiés par Cloudflare et des équipes académiques, les usages réels chez OpenSSH, Signal et Chrome, puis propose un verdict chiffré selon le profil de chaque lecteur. Pour un administrateur système, un développeur ou un responsable sécurité qui doit décider quel algorithme activer sur ses serveurs cette année, la réponse ne se résume pas à une case à cocher dans un fichier de configuration : elle engage la compatibilité avec le parc existant, le budget bande passante et, de plus en plus, des obligations réglementaires venues de Paris et de Bruxelles.

Pourquoi comparer NTRU Prime, ML-KEM-768 et ML-KEM-1024 en 2026

La question n’est plus théorique. Depuis avril 2025, OpenSSH 10.0 fait de l’hybride mlkem768x25519-sha256 son algorithme d’échange de clés par défaut, remplaçant sntrup761x25519-sha512 qui tenait ce rôle depuis OpenSSH 9.0 en avril 2022. Côté navigateur, Chrome a basculé vers le hybride standardisé X25519MLKEM768 à partir de la version 131, abandonnant la variante Kyber pré-standard qu’il testait depuis fin 2023. Cloudflare rapporte dans son blog que près de 70 % du trafic généré par les navigateurs atteignant son réseau utilise désormais une protection hybride post-quantique sur la connexion visiteur-Cloudflare. Ces trois chiffres suffisent à justifier une comparaison sérieuse : l’algorithme qui protège une connexion SSH vers un serveur de production, une conversation Signal ou une session TLS n’est plus un détail d’implémentation, c’est un choix d’architecture qui a des répercussions mesurables.

NTRU Prime, ML-KEM-768 et ML-KEM-1024 partagent un même objectif : résister à un ordinateur quantique capable de casser l’échange de clés Diffie-Hellman classique grâce à l’algorithme de Shor. Mais ils divergent sur la taille des clés, le statut de standardisation, la vitesse d’exécution et, surtout, sur qui les utilise réellement en production. Ce comparatif s’appuie uniquement sur des sources vérifiables : la spécification FIPS 203 du NIST, la documentation Open Quantum Safe, les journaux de version OpenSSH et les publications officielles de Cloudflare.

Trois algorithmes, trois philosophies mathématiques

NTRU Prime, dans sa variante sntrup761, repose sur des réseaux euclidiens (lattices) structurés différemment des schémas retenus par le NIST. Son nom vient d’une volonté délibérée d’éviter certaines structures algébriques jugées potentiellement fragiles par ses concepteurs, Daniel J. Bernstein et son équipe. Le NIST ne l’a pas sélectionné comme standard final, mais Open Quantum Safe lui attribue un niveau de sécurité revendiqué de catégorie 2, et il reste activement maintenu et déployé. Le paramètre 761 dans son nom désigne le degré du polynôme utilisé dans les calculs internes, un choix qui fixe à la fois la sécurité visée et la taille des objets manipulés. Contrairement à d’autres familles de réseaux euclidiens, NTRU Prime évite délibérément certaines décompositions qui simplifient le calcul mais qui, selon ses concepteurs, pourraient aussi simplifier une attaque encore inconnue.

ML-KEM, lui, est la version standardisée de CRYSTALS-Kyber, finalisée par le NIST dans la norme FIPS 203 le 13 août 2024. Il existe en trois tailles : ML-KEM-512 (catégorie 1), ML-KEM-768 (catégorie 3) et ML-KEM-1024 (catégorie 5). Plus la catégorie augmente, plus la marge de sécurité contre une attaque future grandit, au prix de clés et de textes chiffrés plus volumineux. ML-KEM-768 vise un niveau de sécurité comparable à AES-192, tandis que ML-KEM-1024 vise un niveau comparable à AES-256. Les deux partagent la même base mathématique que NTRU Prime, les réseaux euclidiens, mais avec un encodage et des paramètres différents, ce qui explique l’essentiel des écarts de taille observés entre les trois.

Comment ML-KEM a fini par s’imposer face à NTRU Prime

Le processus de sélection du NIST a duré près de huit ans. Lancé en 2016 sous forme d’appel à candidatures ouvert, il a reçu des dizaines de propositions de mécanismes d’encapsulation de clés, dont CRYSTALS-Kyber (devenu ML-KEM) et plusieurs variantes NTRU, incluant NTRU Prime. Le choix final de Kyber comme standard s’est appuyé sur un ensemble de critères publics : la vitesse d’exécution sur matériel courant, la taille des clés, la facilité d’implémentation en code constant (résistant aux attaques par canal auxiliaire) et la maturité de l’analyse cryptographique accumulée par la communauté académique sur les réseaux de modules.

NTRU Prime n’a pas disparu pour autant. Son équipe de conception, emmenée par Daniel J. Bernstein, a fait un choix différent dès le départ : éviter toute structure algébrique qui pourrait un jour faciliter une attaque imprévue, même au prix d’une implémentation plus délicate à optimiser. Ce positionnement prudent lui a valu une adoption précoce dans OpenSSH, bien avant que le NIST ne publie sa norme finale. Résultat paradoxal : pendant près de trois ans, entre avril 2022 et septembre 2024, l’algorithme post-quantique le plus utilisé au monde dans un outil grand public n’était pas celui que le NIST allait finir par choisir.

Tableau comparatif des spécifications officielles

Les chiffres ci-dessous proviennent directement de la spécification FIPS 203 du NIST (tableau 3) pour ML-KEM-768 et ML-KEM-1024, et de la documentation Open Quantum Safe ainsi que de l’implémentation de référence pour NTRU Prime sntrup761.

Caractéristique	NTRU Prime (sntrup761)	ML-KEM-768	ML-KEM-1024
Statut de standardisation	Non retenu par le NIST, candidat alternatif	Standard FIPS 203 (NIST)	Standard FIPS 203 (NIST)
Catégorie de sécurité revendiquée	Niveau 2 (OQS)	Catégorie 3	Catégorie 5
Taille de clé publique	1 158 octets	1 184 octets	1 568 octets
Taille du texte chiffré (ciphertext)	1 039 octets	1 088 octets	1 568 octets
Taille de clé privée (forme étendue)	1 763 octets	2 400 octets	3 168 octets
Secret partagé généré	32 octets	32 octets	32 octets
Base mathématique	Réseaux euclidiens (NTRU structuré)	Réseaux de modules (Kyber)	Réseaux de modules (Kyber)
Premier déploiement en production	OpenSSH 8.5, mars 2021 (optionnel)	OpenSSH 9.9, septembre 2024	Variante Kyber-1024 chez Signal, septembre 2023
Version OpenSSH où il devient défaut	OpenSSH 9.0, avril 2022	OpenSSH 10.0, avril 2025	Non utilisé par défaut dans OpenSSH
Adoption notable	Fallback OpenSSH, systèmes embarqués	Chrome 131, Cloudflare, OpenSSH 10+	Signal (variante Kyber), environnements à exigence maximale
Hybridation recommandée	Toujours combiné à X25519	Toujours combiné à X25519 (X25519MLKEM768)	Généralement combiné à X25519 ou X448

Ce tableau révèle un point souvent ignoré : l’écart entre ML-KEM-768 et ML-KEM-1024 sur la clé privée atteint 768 octets, et l’écart entre NTRU Prime et ML-KEM-1024 sur ce même champ dépasse 1 405 octets, soit environ 1,4 Ko. C’est ce différentiel qui structure tout le reste du comparatif, de la bande passante au choix d’architecture.

Qui utilise quoi : OpenSSH, Signal, Chrome et Cloudflare

Le cas OpenSSH illustre une transition en quatre étapes bien documentées. OpenSSH 8.5, publié le 3 mars 2021, a introduit sntrup761x25519-sha512, mais désactivé par défaut. OpenSSH 9.0, le 8 avril 2022, en a fait le premier échange de clés post-quantique activé par défaut dans un outil SSH grand public, un tournant pour l’écosystème. OpenSSH 9.9, publié le 19 septembre 2024, a ajouté mlkem768x25519-sha256 en parallèle. OpenSSH 10.0, le 9 avril 2025, a fait de cet hybride ML-KEM le nouveau défaut, reléguant NTRU Prime au rang de solution de repli pour les clients anciens.

Signal a pris un chemin différent. Dès septembre 2023, l’application a déployé PQXDH, un protocole d’échange de clés post-quantique combinant X25519 et une variante Kyber-1024, soit les mêmes tailles de clés que ML-KEM-1024 aujourd’hui standardisé. Le choix d’une variante de catégorie 5 plutôt que 768 reflète la priorité donnée par Signal à la confidentialité à très long terme des messages, un choix de conception plus proche de la prudence maximale que de l’optimisation de bande passante.

Côté navigateur, Chrome a d’abord testé un hybride Kyber pré-standard fin 2023, puis a migré vers le X25519MLKEM768 définitif à partir de la version 131 une fois la norme FIPS 203 publiée. Cloudflare, qui expose ces statistiques via son propre blog, confirme avoir observé qu’environ 50 % des connexions TLS atteignant son réseau étaient protégées contre les attaques de type store now, decrypt later dès octobre 2025, un chiffre monté à près de 70 % du trafic navigateur un an plus tard selon sa publication de 2026 sur la visibilité post-quantique par domaine.

Du côté des grands fournisseurs cloud, la visibilité publique est plus inégale. Amazon Web Services et Google Cloud ont confirmé travailler sur le support TLS post-quantique dans leurs services managés, mais aucun des deux ne publie, à la date de rédaction, un calendrier précis indiquant quand ML-KEM-768 ou ML-KEM-1024 deviendra le défaut sur leurs load balancers ou leurs API publiques. Cette asymétrie d’information entre les éditeurs de navigateurs, qui communiquent largement sur leurs chiffres d’adoption, et les fournisseurs d’infrastructure, plus discrets, complique la tâche des équipes qui doivent planifier leur propre migration en fonction de ce que leurs fournisseurs supportent réellement.

Benchmarks de performance : ce que montrent les sources indépendantes

Trois types de sources permettent de comparer la vitesse réelle de ces algorithmes, et elles ne mesurent pas toujours la même chose, ce qui impose de la prudence dans la lecture des chiffres.

Une étude académique de comparaison des mécanismes post-quantiques standardisés et candidats, publiée sur Semantic Scholar, mesure les opérations en microsecondes sur un processeur x86-64 moderne. Elle relève qu’en passant de ML-KEM-512 à ML-KEM-1024, le temps de génération de clé grimpe de 11,664 µs à 27,316 µs, et le temps de décapsulation de 13,719 µs à 30,247 µs. Pour ML-KEM-768, la même étude mesure une génération de clé à 18,493 µs, une encapsulation à 19,311 µs et une décapsulation à 21,366 µs. Ces chiffres montrent une progression quasi linéaire du coût CPU avec la taille des paramètres, sans rupture brutale entre les trois niveaux.

Côté production réelle, Cloudflare a publié dans son bilan 2025 sur l’état du post-quantique sur Internet des mesures d’impact à l’échelle de son réseau plutôt que des microbenchmarks isolés. L’entreprise rapporte qu’un échange de clés hybride post-quantique ajoute environ 4 % de temps de prise de contact (handshake) TLS, avec environ 1,1 Ko de données supplémentaires du serveur vers le client et 1,2 Ko du client vers le serveur, soit environ 2,3 Ko au total par connexion. Ce chiffre de référence, mesuré sur du trafic de production et non en laboratoire, a plus de poids opérationnel que les microbenchmarks de calcul pur.

Pour la signature post-quantique ML-DSA, utilisée séparément des mécanismes d’échange de clés étudiés ici mais sur le même type d’infrastructure, Cloudflare donne un ordre de grandeur utile pour comprendre l’échelle du problème : remplacer les signatures classiques par ML-DSA-44 ajouterait environ 15 Ko par poignée de main. À raison de 18 millions de connexions TLS établies chaque seconde sur son réseau, cela représenterait environ 2,1 Tbps de trafic supplémentaire, soit 0,5 % de la capacité totale du réseau Cloudflare. Aucun des mécanismes d’échange de clés comparés ici n’atteint ce niveau d’impact, mais le calcul donne une méthode fiable pour estimer le coût réel d’une migration à grande échelle.

Pour NTRU Prime, aucune des sources consultées ne fournit de microbenchmark isolé et directement comparable aux chiffres ML-KEM ci-dessus, dans les mêmes conditions matérielles et logicielles. Les documentations disponibles décrivent l’algorithme comme globalement du même ordre de grandeur que ML-KEM-768 en vitesse d’exécution, sa clé privée plus légère compensant partiellement une implémentation réputée plus complexe. Mieux vaut l’indiquer explicitement que d’inventer un chiffre précis qui n’existe dans aucune publication vérifiable.

Ce manque de benchmark unifié entre les trois algorithmes, sur le même processeur et la même implémentation, reste d’ailleurs une limite générale de la littérature publique sur le post-quantique. Les équipes qui doivent choisir en toute rigueur entre NTRU Prime et ML-KEM pour un usage critique ont donc intérêt à lancer leurs propres mesures avec liboqs sur leur matériel cible, plutôt que de se fier à des chiffres glanés sur des plateformes différentes. La bibliothèque Open Quantum Safe fournit justement un harnais de benchmark standardisé à cet effet, utilisable en quelques commandes sur Linux, macOS ou Windows.

Le prix caché de la taille : bande passante et coût cloud

Comment calculer le coût réel d’un surplus d’octets

Un mécanisme d’échange de clés plus volumineux ne coûte rien à l’unité, mais la facture change à l’échelle d’un fournisseur cloud ou d’un grand service web. Pour objectiver ce coût, on multiplie le poids ajouté par la poignée de main (clé publique plus texte chiffré, puisque les deux transitent sur le réseau dans un échange hybride) par le nombre de connexions, puis par le tarif d’égress publié par chaque fournisseur. Les tarifs ci-dessous sont ceux affichés publiquement en 2026 : Amazon Web Services facture 0,09 $/Go pour les 10 premiers To mensuels de trafic sortant vers Internet (identique à Paris et en Virginie), Google Cloud facture entre 0,08 et 0,12 $/Go selon la région, Microsoft Azure facture 0,087 $/Go sur la même tranche, et Cloudflare facture 0,025 $/Go au-delà d’un volume inclus de 1 To sur ses offres payantes en Amérique du Nord et en Europe.

Fournisseur cloud	Tarif égress publié	Coût estimé / 1 Md de handshakes NTRU Prime	Coût estimé / 1 Md ML-KEM-768	Coût estimé / 1 Md ML-KEM-1024
Amazon Web Services	0,09 $/Go (10 premiers To)	≈ 198 $	≈ 204 $	≈ 282 $
Google Cloud	0,08 à 0,12 $/Go selon région	≈ 198 à 264 $	≈ 204 à 273 $	≈ 282 à 376 $
Microsoft Azure	0,087 $/Go (10 premiers To)	≈ 191 $	≈ 198 $	≈ 273 $
Cloudflare (au-delà du forfait inclus)	0,025 $/Go	≈ 55 $	≈ 57 $	≈ 78 $
Licence logicielle (OpenSSH, liboqs, OpenSSL)	Open source	0 $	0 $	0 $

Le constat est double. D’abord, l’écart de coût entre les trois algorithmes reste modeste en absolu, quelques dizaines à quelques centaines de dollars pour un milliard de connexions, ce qui écarte le coût pur de bande passante comme critère décisif pour la plupart des organisations. Ensuite, ML-KEM-1024 coûte systématiquement entre 38 % et 42 % de plus que ML-KEM-768 selon le fournisseur, un écart qui devient significatif uniquement pour les opérateurs traitant plusieurs dizaines de milliards de connexions par mois, le profil de Cloudflare ou d’un grand fournisseur de messagerie comme Signal. Pour une PME ou une administration de taille moyenne, l’écart tient de l’arrondi comptable.

Ce calcul ignore volontairement un facteur plus difficile à chiffrer : le coût de la mémoire et du CPU sur les équipements réseau qui terminent des millions de connexions simultanées, comme les répartiteurs de charge ou les pare-feux applicatifs. Une clé privée de 3 168 octets occupe presque le double de place en mémoire qu’une clé de 1 763 octets, un détail négligeable sur un serveur mais qui compte sur un boîtier réseau dimensionné pour des centaines de milliers de sessions concurrentes. C’est l’une des raisons pour lesquelles Cloudflare et les grands opérateurs de CDN ont historiquement privilégié ML-KEM-768 plutôt que ML-KEM-1024 pour leur trafic de masse, réservant la variante la plus lourde à des cas d’usage plus ciblés.

Cas d’usage : quel algorithme choisir selon votre contexte

Le choix entre les trois mécanismes dépend moins de la performance brute que du profil de menace, du parc logiciel existant et des contraintes réglementaires.

Administrateurs système gérant des serveurs SSH récents : adopter l’hybride ML-KEM-768 (mlkem768x25519-sha256), défaut d’OpenSSH depuis la version 10.0, sans configuration supplémentaire nécessaire.
Parcs hétérogènes avec clients OpenSSH antérieurs à la version 9.9 : conserver temporairement sntrup761x25519-sha512 en compatibilité, car il reste supporté comme solution de repli et offre déjà une résistance quantique réelle.
Banques, assurances, opérateurs d’infrastructures critiques : envisager ML-KEM-1024 pour les systèmes dont les données doivent rester confidentielles sur plusieurs décennies, en cohérence avec les orientations de prudence maximale que l’ANSSI recommande pour les usages à long terme.
Applications de messagerie et de communication chiffrée : suivre la logique de Signal, qui a choisi dès 2023 la variante de catégorie 5 plutôt que 768, par priorité donnée à la marge de sécurité sur l’optimisation de bande passante.
Services web à très fort volume de connexions (CDN, API publiques) : privilégier ML-KEM-768, le choix retenu par Chrome et Cloudflare, qui offre le meilleur compromis entre sécurité de catégorie 3 et poids réseau minimal à grande échelle.
Systèmes embarqués ou contraints en mémoire : évaluer soigneusement l’impact de la clé privée étendue (jusqu’à 3 168 octets pour ML-KEM-1024) sur des équipements à ressources limitées avant de migrer, et envisager NTRU Prime comme compromis transitoire si la plateforme le supporte déjà.

L’impact sur les appareils contraints et l’Internet des objets

Les tableaux de spécifications ci-dessus parlent d’octets, mais sur un microcontrôleur ou un objet connecté à faible mémoire, ces octets pèsent différemment que sur un serveur cloud. Un module embarqué typique dispose parfois de quelques dizaines de kilo-octets de RAM disponible pour l’ensemble de sa pile réseau. Dans ce contexte, la différence entre une clé privée ML-KEM-768 de 2 400 octets et une clé privée ML-KEM-1024 de 3 168 octets représente un delta de 768 octets, soit potentiellement plusieurs pourcents de la mémoire totale disponible sur l’appareil. Pour NTRU Prime, la clé privée de 1 763 octets reste la plus légère des trois options sérieuses, ce qui explique pourquoi certains fabricants de matériel embarqué continuent à l’évaluer malgré son absence de standardisation NIST.

Cette contrainte mémoire s’ajoute à un autre problème pratique : la plupart des piles cryptographiques légères conçues pour l’IoT n’intègrent pas encore nativement ML-KEM ou NTRU Prime, et le portage demande souvent un travail d’adaptation non négligeable. Les équipes qui conçoivent des produits connectés destinés à rester en service une décennie ou plus, comme des compteurs intelligents ou des capteurs industriels, doivent donc anticiper cette migration bien avant qu’elle ne devienne obligatoire, sous peine de devoir remplacer du matériel physique plutôt que de simplement mettre à jour un logiciel.

Guide de migration : passer à un échange de clés post-quantique

La migration vers un KEM post-quantique hybride suit un parcours similaire que l’on parte de zéro ou que l’on modernise une infrastructure existante.

Faire l’inventaire des versions OpenSSH, OpenSSL ou des bibliothèques TLS déployées sur l’ensemble du parc, serveurs comme postes clients.
Vérifier que chaque composant atteint au minimum OpenSSH 9.9 ou une bibliothèque intégrant ML-KEM via liboqs, OpenSSL 3.5 ou une build équivalente.
Activer explicitement l’algorithme mlkem768x25519-sha256 côté serveur et client si la version le propose mais ne l’active pas encore par défaut.
Conserver sntrup761x25519-sha512 en liste de compatibilité pour les clients plus anciens, le temps que le parc complet soit mis à jour.
Mesurer l’impact réel sur la latence et la bande passante avec les outils de supervision existants, en se référant au repère Cloudflare d’environ 4 % de ralentissement de la poignée de main.
Évaluer si le profil de risque justifie de passer directement à ML-KEM-1024 pour certains systèmes sensibles, en tenant compte du surcoût de bande passante chiffré plus haut.
Suivre le calendrier réglementaire : la Commission européenne demande aux États membres d’entamer la transition post-quantique avant fin 2026, et l’ANSSI prévoit de ne plus certifier de produits dépourvus de cryptographie post-quantique à partir de 2027.

Pour vérifier concrètement quels algorithmes un serveur SSH propose, la commande suivante liste les méthodes d’échange de clés supportées côté client OpenSSH :

ssh -Q kex

# Forcer explicitement l'hybride ML-KEM-768 pour une connexion
ssh -o KexAlgorithms=mlkem768x25519-sha256 utilisateur@serveur

# Vérifier l'algorithme négocié lors d'une connexion en mode verbeux
ssh -vv utilisateur@serveur 2>&1 | grep "kex: algorithm"

Côté serveur, le fichier sshd_config permet de restreindre ou de prioriser les algorithmes acceptés :

# /etc/ssh/sshd_config
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

Avantages et inconvénients de chaque algorithme

NTRU Prime (sntrup761)

Avantage : clé privée la plus légère des trois (1 763 octets), déployé et éprouvé en production depuis 2021.
Avantage : conception volontairement prudente sur le choix des structures algébriques, selon ses auteurs.
Inconvénient : non retenu par le NIST comme standard final, ce qui limite son adoption à long terme hors écosystème OpenSSH.
Inconvénient : de moins en moins choisi comme défaut, désormais relégué au rôle de solution de repli.

ML-KEM-768

Avantage : standard officiel FIPS 203, adopté par OpenSSH, Chrome et Cloudflare comme défaut.
Avantage : meilleur compromis taille/sécurité pour les déploiements à très grande échelle.
Inconvénient : catégorie de sécurité 3, donc marge inférieure à ML-KEM-1024 pour les données devant rester confidentielles plusieurs décennies.
Inconvénient : clé privée étendue plus lourde que celle de NTRU Prime (2 400 contre 1 763 octets).

ML-KEM-1024

Avantage : catégorie de sécurité 5, la marge la plus large disponible dans le standard FIPS 203.
Avantage : choix retenu par Signal pour la confidentialité à long terme des communications.
Inconvénient : surcoût de bande passante de 38 à 42 % par rapport à ML-KEM-768 selon le fournisseur cloud.
Inconvénient : clé privée la plus lourde des trois (3 168 octets), un facteur à surveiller sur systèmes contraints.

Ce que disent la France et l’Europe sur ces choix

L’ANSSI et ses partenaires du G7 ont publié un appel conjoint rappelant que la transition post-quantique prendra plus d’une décennie et touchera l’ensemble de l’écosystème de cybersécurité, pas seulement le remplacement ponctuel d’un algorithme. L’agence recommande aux organisations françaises de commencer immédiatement un inventaire de leurs systèmes cryptographiques, de leurs clés et de leurs certificats, sans attendre une échéance réglementaire. Sa position affichée est qu’acheter, après 2030, un produit dépourvu d’intégration post-quantique ne serait plus raisonnable.

Au niveau européen, la Commission demande à l’ensemble des États membres d’entamer la transition post-quantique avant la fin de 2026, avec une échéance plus stricte, fin 2030, pour les usages à haut risque. La transition la plus large, incluant les systèmes moins critiques, est attendue d’ici 2035 là où c’est réalisable. Dans ce cadre réglementaire, aucune des deux institutions n’impose explicitement ML-KEM-768 plutôt que ML-KEM-1024 : le choix du paramètre reste une décision d’ingénierie propre à chaque organisation, tant que l’algorithme retenu figure dans la liste des standards reconnus, ce qui exclut de fait NTRU Prime comme choix de long terme pour les nouveaux déploiements soumis à certification.

Pour les équipes françaises soumises à des obligations sectorielles, comme les opérateurs de services essentiels visés par la directive NIS2 ou les acteurs financiers concernés par DORA, ce flou sur le paramètre exact à retenir n’est pas forcément une mauvaise nouvelle. Il laisse une marge de décision technique, à condition de documenter le choix fait et sa justification face à un auditeur. Dans la pratique, la plupart des architectes sécurité consultés dans les publications spécialisées recommandent de partir de ML-KEM-768 comme base, puis de réévaluer vers ML-KEM-1024 uniquement pour les flux identifiés comme les plus sensibles lors d’une cartographie des risques, plutôt que d’appliquer un paramètre unique à l’ensemble du système d’information.

Cryptanalyse et limites actuelles des trois mécanismes

Aucune des sources consultées pour cet article ne documente de rupture cryptanalytique vérifiée contre ML-KEM ou NTRU Prime en 2025 ou 2026. Les deux familles reposent sur des problèmes de réseaux euclidiens considérés comme difficiles même pour un ordinateur quantique, et ML-KEM a traversé plusieurs années d’examen public dans le cadre du processus de standardisation du NIST avant sa finalisation en août 2024. Cela ne signifie pas une sécurité éternelle garantie, mais plutôt l’absence, à ce jour, d’un résultat public remettant en cause les paramètres actuels.

Le vrai risque à court terme se situe moins dans les mathématiques que dans l’implémentation : une bibliothèque mal codée, un canal auxiliaire (side-channel) mal protégé ou une mauvaise gestion de la rétrocompatibilité peuvent affaiblir un algorithme par ailleurs solide. C’est précisément pour cette raison que les hybrides combinant toujours un composant classique (X25519) avec le composant post-quantique restent la norme recommandée : si un défaut imprévu touchait un jour ML-KEM ou NTRU Prime, la partie classique continuerait de fournir une protection contre les attaques non quantiques pendant que la communauté corrige le problème.

Un autre point de vigilance concerne la gestion des versions pré-standard. Avant la publication de FIPS 203 en août 2024, plusieurs projets, dont Chrome et Signal, utilisaient des versions antérieures de Kyber qui n’étaient pas strictement identiques à ML-KEM final sur le plan des constantes internes. Les équipes qui ont déployé ces versions précoces ont dû planifier une migration vers la version standardisée, une opération transparente pour l’utilisateur final mais qui a demandé une coordination technique réelle entre les éditeurs de navigateurs et les opérateurs de serveurs pendant la période de transition 2023-2024.

Verdict : quel algorithme pour quel besoin

Les chiffres rassemblés dans ce comparatif pointent vers une hiérarchie claire. ML-KEM-768 s’impose comme le choix par défaut pour la grande majorité des usages : c’est l’algorithme que retiennent OpenSSH 10, Chrome 131 et Cloudflare, il offre une catégorie de sécurité 3 largement suffisante pour la plupart des menaces projetées, et son surcoût de bande passante reste le plus faible des trois options post-quantiques sérieuses. NTRU Prime garde un rôle utile de transition et de compatibilité, mais son absence de standardisation NIST en fait un choix à éviter pour tout nouveau déploiement de long terme. ML-KEM-1024 se réserve aux cas où la donnée protégée doit rester confidentielle plusieurs décennies, à l’image du choix fait par Signal, ou là où une réglementation sectorielle impose la catégorie de sécurité maximale, au prix d’un surcoût de bande passante mesuré entre 38 % et 42 % selon le fournisseur cloud.

Pour la majorité des équipes techniques françaises et européennes qui lisent ce comparatif, la décision la plus simple reste la plus efficace : mettre à jour OpenSSH vers la version 10 ou plus récente, vérifier que les bibliothèques TLS utilisées proposent bien l’hybride X25519MLKEM768, et garder ML-KEM-1024 en réserve pour les systèmes dont le profil de risque le justifie vraiment.

Le tableau ci-dessous résume ce verdict en une phrase par algorithme, à garder sous la main lors de la prochaine revue d’architecture sécurité.

NTRU Prime (sntrup761) : solution de transition fiable mais sans avenir de standardisation, à ne plus choisir pour un nouveau projet en 2026.
ML-KEM-768 : le choix par défaut pour la quasi-totalité des usages SSH, TLS et API, validé par OpenSSH, Chrome et Cloudflare.
ML-KEM-1024 : réservé aux données à confidentialité décennale ou aux exigences réglementaires de catégorie 5, au prix d’un surcoût mesurable mais gérable.

Questions fréquentes

Qu’est-ce que ML-KEM-768 et pourquoi est-il devenu la norme ?

ML-KEM-768 est la variante de catégorie 3 du mécanisme d’encapsulation de clés standardisé par le NIST dans FIPS 203 en août 2024. Il est devenu la norme de fait parce qu’OpenSSH l’a fait défaut en avril 2025, Chrome l’utilise depuis sa version 131, et Cloudflare le déploie à grande échelle sur son réseau, créant un effet d’entraînement sur l’ensemble de l’écosystème.

NTRU Prime est-il toujours sûr à utiliser en 2026 ?

Rien dans les sources disponibles n’indique une faille documentée contre NTRU Prime en 2026. Il reste supporté comme solution de repli dans OpenSSH. Son principal désavantage n’est pas la sécurité mais le statut : n’étant pas un standard NIST, son avenir à long terme dans les nouveaux déploiements certifiés reste incertain.

Pourquoi Signal utilise-t-il un mécanisme plus volumineux que ML-KEM-768 ?

Signal a déployé son protocole PQXDH dès septembre 2023 avec une variante Kyber-1024, de taille équivalente à l’actuel ML-KEM-1024. Le choix reflète une priorité donnée à la marge de sécurité maximale pour des communications dont la confidentialité doit tenir plusieurs décennies, plutôt qu’à l’optimisation du poids réseau.

Faut-il migrer tous ses serveurs SSH vers ML-KEM-768 dès maintenant ?

Pour tout parc utilisant déjà OpenSSH 9.9 ou plus récent, l’hybride ML-KEM-768 est disponible et il suffit souvent d’une mise à jour vers OpenSSH 10 pour qu’il devienne le défaut. Les environnements avec des clients plus anciens peuvent conserver temporairement NTRU Prime en compatibilité pendant la transition.

ML-KEM-1024 est-il obligatoire pour les banques et administrations françaises ?

Ni l’ANSSI ni la Commission européenne n’imposent explicitement ML-KEM-1024 plutôt que ML-KEM-768 dans leurs recommandations actuelles. L’ANSSI recommande surtout l’hybridation systématique et prévoit de refuser la certification de produits sans cryptographie post-quantique à partir de 2027, sans fixer un paramètre unique obligatoire pour tous les usages.

Les algorithmes post-quantiques ralentissent-ils vraiment les connexions au quotidien ?

Selon les mesures de production publiées par Cloudflare, l’impact mesuré est d’environ 4 % de temps de poignée de main supplémentaire et environ 2,3 Ko de données en plus par connexion. Pour l’utilisateur final, cet effet reste généralement imperceptible sur une connexion Internet moderne.

NTRU Prime sera-t-il un jour standardisé par le NIST ?

Rien dans les publications actuelles du NIST n’indique un projet de standardisation future de NTRU Prime. L’institut a choisi ML-KEM comme standard d’encapsulation de clés dans FIPS 203, et les ressources disponibles ne mentionnent aucune démarche en cours pour faire évoluer ce statut.

Quelle est la différence entre un KEM post-quantique et une signature post-quantique ?

Un mécanisme d’encapsulation de clés (KEM) comme ML-KEM ou NTRU Prime sert à établir un secret partagé entre deux parties, l’équivalent post-quantique d’un échange Diffie-Hellman. Une signature post-quantique, comme ML-DSA, sert à authentifier l’origine d’un message ou d’un certificat. Les deux sont complémentaires dans une connexion TLS ou SSH complète, mais répondent à des besoins distincts et suivent des calendriers de migration différents.

Combien coûte réellement une migration vers ces algorithmes pour une petite structure ?

Pour une PME ou une petite administration, le coût direct est quasiment nul : OpenSSH, OpenSSL et les bibliothèques intégrant liboqs restent des logiciels open source, et la mise à jour vers une version récente suffit dans la majorité des cas. Le surcoût de bande passante calculé plus haut, de l’ordre de quelques centaines de dollars pour un milliard de connexions, ne devient pertinent qu’à l’échelle d’un très grand opérateur. Le vrai coût, pour une structure de taille modeste, réside dans le temps d’ingénierie nécessaire pour auditer son parc, tester la compatibilité des clients anciens et planifier une bascule progressive plutôt que brutale.