OpenSSH a changé de mécanisme d’échange de clés par défaut cette année, et le choix dit beaucoup sur l’état réel de la course post-quantique. Depuis la version 10.0, le client et le serveur négocient désormais mlkem768x25519-sha256 en priorité, reléguant l’ancien hybride fondé sur NTRU Prime, sntrup761x25519-sha512, au rang d’option disponible mais plus secondaire. Entre les deux algorithmes, l’écart technique est minime : 26 octets sur la clé publique, 49 sur le chiffré. Mais l’écart réglementaire, lui, est décisif. ML-KEM a été gravé dans le marbre par le NIST sous la référence FIPS 203 le 13 août 2024, tandis que NTRU Prime n’a jamais obtenu de voie de standardisation fédérale, un choix documenté depuis 2022 dans le rapport NIST IR 8413. Ce 13 octobre 2026, une certification NIST CAVP décrochée par un fournisseur taïwanais de modules matériels de sécurité remet ce dossier sur le devant de la scène, avec des conséquences directes pour les entreprises et administrations européennes qui doivent choisir leur pile cryptographique post-quantique avant la fin de la décennie.
ML-KEM et NTRU Prime : deux réponses au même problème
Les deux algorithmes répondent à la même menace : un ordinateur quantique suffisamment puissant casserait en quelques heures les échanges de clés basés sur RSA ou les courbes elliptiques, grâce à l’algorithme de Shor. ML-KEM et NTRU Prime appartiennent tous deux à la famille des mécanismes d’encapsulation de clés (KEM) fondés sur les réseaux euclidiens, une construction mathématique jugée résistante aux calculateurs quantiques connus à ce jour. La ressemblance s’arrête à peu près là. ML-KEM dérive directement de Kyber, le candidat retenu par le NIST à l’issue de son concours de standardisation lancé en 2016 et conclu en 2022. NTRU Prime, de son côté, est une variante durcie du schéma NTRU historique, conçue notamment pour éviter certaines structures algébriques jugées risquées à long terme par ses auteurs, dont Daniel J. Bernstein.
Sur le papier, les deux approches livrent des performances comparables. C’est justement cette proximité qui rend le choix du NIST, et maintenant celui d’OpenSSH, aussi révélateur. Il ne s’agit pas d’un algorithme qui écrase l’autre en vitesse brute, mais d’un choix de gouvernance : celui qui bénéficie d’une norme fédérale l’emporte, même quand l’écart technique se compte en dizaines d’octets.
FIPS 203 : la norme qui a fait basculer l’industrie
ML-KEM est la version normalisée de Kyber. Le NIST a publié le standard FIPS 203 le 13 août 2024, et le texte est entré en application le lendemain. La norme définit trois niveaux de sécurité. ML-KEM-512 utilise une clé publique de 800 octets, une clé secrète de 1 632 octets, un chiffré de 768 octets et un secret partagé de 32 octets. ML-KEM-768, le niveau le plus déployé en pratique, monte à 1 184 octets pour la clé publique, 2 400 octets pour la clé secrète et 1 088 octets pour le chiffré. ML-KEM-1024, réservé aux usages les plus sensibles, atteint 1 568 octets de clé publique, 3 168 octets de clé secrète et 1 568 octets de chiffré.
Ce qui change la donne pour les entreprises n’est pas la taille des clés, mais le statut juridique du texte. FIPS 203 s’inscrit dans le programme FIPS 140-3, celui que doivent respecter les modules cryptographiques vendus aux agences fédérales américaines et, par ricochet, à une large partie des grands comptes qui exigent une conformité équivalente en Europe. Un fournisseur qui veut vendre un module matériel de chiffrement post-quantique à une banque, une administration ou un opérateur d’infrastructure critique a aujourd’hui besoin d’une certification CAVP alignée sur FIPS 203. NTRU et NTRU Prime n’ont pas cette case à cocher, et ne l’auront pas tant que le NIST ne change pas de position.
NTRU Prime : l’alternative qui a gardé sa place dans SSH
NTRU Prime n’a pourtant rien d’un algorithme marginal. Sa variante sntrup761 affiche une clé publique de 1 158 octets, un chiffré de 1 039 octets, une clé secrète de 1 763 octets et un secret partagé de 32 octets, pour un degré premier p égal à 761. Elle avait été intégrée à OpenSSH dès 2022, bien avant que ML-KEM n’existe sous sa forme normalisée, précisément parce que ses concepteurs voulaient une alternative disponible immédiatement, sans attendre la fin du processus NIST. L’équipe OpenSSH a justifié ce choix à l’époque par la volonté de déployer une protection hybride post-quantique le plus tôt possible, quitte à basculer plus tard vers l’algorithme retenu par le NIST une fois celui-ci stabilisé.
C’est exactement ce qui vient de se produire. Le passage à ML-KEM n’efface pas NTRU Prime du code d’OpenSSH : l’option reste disponible pour qui veut la forcer explicitement dans sa configuration. Mais elle n’est plus le choix que reçoit un administrateur système qui laisse les réglages par défaut, ce qui, dans la pratique, pèse beaucoup plus que n’importe quel argument de performance théorique.
Le tournant OpenSSH : de sntrup761x25519 à mlkem768x25519
Le changement est documenté dans les notes de version d’OpenSSH 10.0 et confirmé par les relevés techniques publiés depuis. Le mécanisme hybride désormais prioritaire, mlkem768x25519-sha256, combine ML-KEM-768 avec la courbe elliptique classique X25519. Cette construction hybride n’est pas un hasard : elle garantit que même si une faille venait à toucher ML-KEM, la partie classique X25519 continuerait d’offrir une protection, et inversement pour le cas d’un ordinateur quantique opérationnel. L’ancien standard par défaut, sntrup761x25519-sha512, combinait NTRU Prime avec la même courbe X25519, selon une logique de défense en profondeur identique.
Pour un administrateur système, la bascule est largement invisible : les deux mécanismes s’activent automatiquement dans les connexions SSH modernes, sans intervention manuelle, dès que le client et le serveur exécutent une version récente. C’est précisément ce qui inquiète certains experts en cryptographie appliquée : un changement d’algorithme fondamental qui passe sans qu’aucune alerte ne s’affiche à l’écran de l’utilisateur final. La robustesse du nouveau choix dépend donc entièrement de la confiance accordée au processus de sélection du NIST, un processus que critiquent justement les partisans de NTRU Prime, qui jugent la procédure trop centralisée.
Comparatif technique : tailles de clés et de chiffrés
Le tableau suivant reprend les paramètres publics des trois niveaux de ML-KEM et de sntrup761, la variante de NTRU Prime utilisée par OpenSSH. Les tailles sont exprimées en octets.
| Algorithme | Clé publique | Clé secrète | Chiffré | Secret partagé | Statut NIST |
|---|---|---|---|---|---|
| ML-KEM-512 | 800 octets | 1 632 octets | 768 octets | 32 octets | FIPS 203 standardisé |
| ML-KEM-768 | 1 184 octets | 2 400 octets | 1 088 octets | 32 octets | FIPS 203 standardisé |
| ML-KEM-1024 | 1 568 octets | 3 168 octets | 1 568 octets | 32 octets | FIPS 203 standardisé |
| NTRU Prime (sntrup761) | 1 158 octets | 1 763 octets | 1 039 octets | 32 octets | Non standardisé NIST |
Deux chiffres méritent d’être isolés. Sur la clé publique, sntrup761 reste légèrement plus compact que ML-KEM-768, avec un écart de 26 octets seulement. Sur le chiffré, l’avantage penche aussi côté NTRU Prime, avec 49 octets de moins que ML-KEM-768. Ces économies paraissent dérisoires à l’échelle d’une connexion SSH individuelle, mais elles comptent dans des contextes où des millions de poignées de main cryptographiques se répètent chaque seconde, par exemple sur les infrastructures de passerelles API à très fort trafic.
Pourquoi le NIST a écarté NTRU Prime de la standardisation
L’exclusion de NTRU Prime du processus fédéral américain n’est pas une question de performance. Le rapport NIST IR 8413, publié en 2022 à l’issue du troisième tour du concours de standardisation post-quantique, détaille les raisons du choix de Kyber (devenu ML-KEM) plutôt que des autres finalistes de la famille des réseaux euclidiens, dont NTRU et NTRU Prime faisaient partie. Le NIST a retenu un seul KEM fondé sur les réseaux pour limiter la surface de maintenance et de certification, et a ensuite ajouté HQC, fondé sur les codes correcteurs d’erreurs, comme deuxième algorithme pour diversifier les hypothèses mathématiques sous-jacentes, plutôt que d’ajouter une deuxième variante de réseau euclidien.
Cette logique explique pourquoi NTRU Prime continue d’exister dans des déploiements réels, comme OpenSSH, sans jamais obtenir le sceau FIPS. Le NIST a tranché qu’un seul schéma de réseau euclidien suffisait pour la norme fédérale, et ce schéma est ML-KEM. Tout le reste, aussi solide soit-il mathématiquement, reste hors du cadre réglementaire américain, et donc hors du cadre que la plupart des régulateurs alignent sur les publications du NIST plutôt que de bâtir leur propre référentiel indépendant.
L’actualité du 13 octobre 2026 : une certification CAVP qui confirme la tendance
Ce 13 octobre 2026, le fournisseur taïwanais de sécurité informatique Pu Hong (普鴻資訊) a annoncé que treize algorithmes post-quantiques développés en interne venaient de décrocher la certification NIST CAVP, le programme de validation des algorithmes cryptographiques qui sert de porte d’entrée à la conformité FIPS 140-3. La validation couvre explicitement FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA), ainsi que trois modes de chiffrement AES (CBC, ECB, GCM). L’entreprise prévoit d’intégrer ces briques certifiées dans sa gamme de modules matériels de sécurité (HSM) et dans sa ligne de protection de données ProTrust, selon les communiqués relayés par la presse économique taïwanaise, dont le quotidien TechNews et Economic Daily News.
Rien dans cette annonce ne mentionne NTRU Prime, et c’est justement ce silence qui est parlant. Un an après l’entrée en vigueur de FIPS 203, les fournisseurs de matériel de sécurité qui veulent vendre à des clients soumis à des exigences de conformité fédérale ou équivalente alignent systématiquement leurs feuilles de route sur ML-KEM, ML-DSA et SLH-DSA, les trois standards publiés par le NIST. NTRU Prime, malgré sa présence réelle dans l’écosystème SSH, n’apparaît dans aucune de ces annonces de certification parce qu’aucun organisme de certification officiel ne reconnaît ce schéma comme référence fédérale.
Ce que cela change pour les entreprises et administrations européennes
Pour une direction des systèmes d’information en France ou ailleurs en Europe, le signal est clair même sans texte réglementaire spécifique sur ce point précis. Les équipes qui achètent des modules de sécurité, des pare-feux, des solutions VPN ou des passerelles SSH veulent des produits dont la cryptographie post-quantique a été validée par un processus reconnu, et ML-KEM coche cette case alors que NTRU Prime ne la coche pas. Les éditeurs de logiciels, les fournisseurs de cloud et les opérateurs d’infrastructures critiques suivent la même logique que les acheteurs publics américains, parce que le marché des certifications de sécurité est largement mondialisé et que peu d’acteurs ont intérêt à maintenir deux piles cryptographiques distinctes selon la zone géographique du client.
Concrètement, une entreprise qui gère une flotte de serveurs accessibles par SSH n’a aujourd’hui rien à faire de particulier : la mise à jour vers OpenSSH 10.0 ou une version plus récente bascule automatiquement vers ML-KEM dès que les deux extrémités de la connexion le supportent. Le vrai travail de migration se situe en amont, chez les éditeurs de bibliothèques cryptographiques, les fabricants de HSM et les fournisseurs de VPN, qui doivent décider où investir leurs efforts de certification. L’annonce de Pu Hong montre que, pour ces acteurs, la décision est déjà prise.
Conformité et calendrier : où se situe l’Europe
La cryptographie post-quantique est devenue un sujet de conformité autant qu’un sujet technique. Le tableau ci-dessous résume les jalons publics les plus établis pour situer ML-KEM et NTRU Prime dans ce calendrier, sans attribuer aux régulateurs européens des positions qui n’ont pas été confirmées spécifiquement sur l’opposition ML-KEM contre NTRU Prime.
| Jalon | Date | Portée |
|---|---|---|
| Fin du 3e tour du concours NIST PQC (NIST IR 8413) | 2022 | Sélection de Kyber (futur ML-KEM) et exclusion des variantes NTRU |
| Publication de FIPS 203 (ML-KEM) | 13 août 2024 | Norme fédérale américaine d’échange de clés post-quantique |
| Entrée en vigueur de FIPS 203 | 14 août 2024 | Applicable aux modules cryptographiques fédéraux américains |
| OpenSSH bascule vers mlkem768x25519-sha256 par défaut | Version 10.0 | Remplace sntrup761x25519-sha512 comme hybride par défaut |
| Certification NIST CAVP de Pu Hong (FIPS 203/204/205) | 13 octobre 2026 | Modules HSM et protection de données, marché taïwanais |
Ce calendrier montre une trajectoire cohérente : chaque étape renforce la position de ML-KEM comme référence par défaut, sans qu’aucune étape publique équivalente ne vienne consolider celle de NTRU Prime. L’algorithme de Bernstein garde une niche solide dans les logiciels libres qui privilégient la diversité des hypothèses mathématiques et la défiance envers un processus de standardisation jugé trop centralisé, mais cette niche ne grandit pas au même rythme que l’écosystème ML-KEM.
Un peu d’histoire : de Kyber au duel ML-KEM contre NTRU
La rivalité entre les deux familles d’algorithmes ne date pas d’hier. NTRU, le schéma dont dérive NTRU Prime, a été proposé pour la première fois en 1996 par Jeffrey Hoffstein, Jill Pipher et Joseph Silverman, ce qui en fait l’un des plus anciens schémas de chiffrement à réseaux euclidiens encore étudiés aujourd’hui. Kyber, lui, est né bien plus tard, dans le cadre du concours lancé par le NIST en 2016 pour sélectionner un ensemble d’algorithmes résistants aux ordinateurs quantiques. Les deux familles ont coexisté pendant tout le processus de sélection, chacune portée par des équipes de chercheurs différentes et des choix de conception distincts sur la façon de limiter les risques théoriques propres aux réseaux euclidiens.
Le dénouement du concours en 2022 a consacré Kyber, renommé ML-KEM après sa normalisation. NTRU Prime n’a pas disparu pour autant : porté notamment par Daniel J. Bernstein, un cryptographe connu pour son scepticisme envers les processus de standardisation pilotés par une agence gouvernementale unique, l’algorithme a continué d’exister dans des implémentations indépendantes, dont OpenSSH a été le véhicule de déploiement le plus visible pendant plusieurs années. Le basculement d’OpenSSH vers ML-KEM referme, en partie, ce chapitre d’une décennie de compétition entre deux philosophies de la cryptographie post-quantique : celle qui attend la norme officielle, et celle qui préfère déployer dès que la sécurité semble suffisante.
ML-KEM face aux autres candidats post-quantiques
NTRU Prime n’est pas le seul concurrent de ML-KEM sur le terrain des mécanismes d’encapsulation de clés. HQC, fondé sur les codes correcteurs d’erreurs plutôt que sur les réseaux euclidiens, a été retenu par le NIST comme deuxième standard officiel, précisément pour ne pas dépendre d’une seule famille d’hypothèses mathématiques. Classic McEliece, un autre candidat historique, reste disponible dans certaines implémentations mais souffre de clés publiques nettement plus volumineuses, ce qui limite son usage aux contextes où la taille des clés importe peu face à la marge de sécurité recherchée. FrodoKEM, enfin, mise sur une construction volontairement conservatrice, aux dépens de la taille des clés et de la vitesse.
Face à ce paysage, NTRU Prime occupe une position particulière : ni standard officiel, ni simple curiosité académique, mais un algorithme réellement déployé à grande échelle via OpenSSH depuis plusieurs années, et dont la communauté continue de maintenir des implémentations à jour. C’est cette combinaison, déploiement réel sans reconnaissance fédérale, qui rend le cas NTRU Prime différent de celui des autres candidats écartés du concours NIST, pour lesquels l’usage pratique reste beaucoup plus limité.
Migrer son infrastructure SSH : ce qu’il faut vérifier
Pour une équipe infrastructure qui veut vérifier quel algorithme protège réellement ses connexions SSH, la commande suivante affiche les mécanismes d’échange de clés négociés par le client local.
ssh -Q kex
# Vérifie si mlkem768x25519-sha256 figure dans la liste
# et dans quel ordre de préférence il apparaît
ssh -vv utilisateur@serveur 2>&1 | grep "kex algorithm"
# Affiche l'algorithme réellement négocié lors de la connexionSi l’algorithme négocié reste sntrup761x25519-sha512, la cause la plus fréquente est une version d’OpenSSH antérieure à 10.0 sur l’un des deux points de la connexion, client ou serveur. Forcer explicitement ML-KEM, pour les administrateurs qui veulent anticiper sans attendre une mise à jour générale, passe par l’ajout d’une ligne KexAlgorithms mlkem768x25519-sha256 dans le fichier de configuration SSH, en conservant si possible un repli vers l’ancien hybride pour la compatibilité avec des clients plus anciens pendant la période de transition.
Prédictions : où en sera ce duel fin 2027
- ML-KEM continuera de s’imposer comme choix par défaut dans les nouvelles bibliothèques TLS, SSH et VPN, porté par la pression de conformité FIPS 140-3 plutôt que par un avantage de performance.
- NTRU Prime restera disponible comme option de repli dans OpenSSH et dans quelques distributions Linux soucieuses de diversité algorithmique, sans gagner de nouveaux déploiements majeurs par défaut.
- D’autres fournisseurs de HSM, en Asie comme en Europe, suivront l’exemple de Pu Hong et annonceront des certifications NIST CAVP couvrant FIPS 203, 204 et 205 au cours des prochains trimestres.
- Les éditeurs de bibliothèques cryptographiques open source continueront de maintenir NTRU Prime par principe de défense en profondeur mathématique, même sans normalisation, pour éviter une dépendance totale aux réseaux euclidiens de type Kyber.
- Le débat sur la centralisation du processus de standardisation post-quantique, porté notamment par les défenseurs de NTRU Prime, restera vif dans la communauté cryptographique sans remettre en cause la position dominante de ML-KEM sur le terrain réglementaire.
Foire aux questions
ML-KEM et NTRU Prime sont-ils compatibles entre eux ?
Non. Les deux algorithmes utilisent des constructions mathématiques différentes et produisent des clés et des chiffrés incompatibles. Un client qui négocie ML-KEM ne peut pas communiquer avec un serveur qui n’accepte que NTRU Prime, et inversement, sauf si les deux parties supportent les deux mécanismes.
Pourquoi OpenSSH avait-il choisi NTRU Prime avant ML-KEM ?
Parce que NTRU Prime, via sa variante sntrup761, était disponible et jugé suffisamment mature avant que le NIST ne finalise sa propre norme. L’équipe OpenSSH a préféré déployer une protection post-quantique hybride dès 2022 plutôt que d’attendre la publication officielle de FIPS 203 en 2024.
NTRU Prime est-il moins sûr que ML-KEM ?
Aucune faille pratique connue ne distingue aujourd’hui les deux algorithmes sur le plan de la sécurité cryptographique. La différence tient au statut réglementaire : ML-KEM dispose d’une norme fédérale américaine et d’un programme de certification associé, ce que NTRU Prime n’a pas.
Faut-il désactiver NTRU Prime dans sa configuration SSH ?
Rien n’y oblige. NTRU Prime reste un mécanisme hybride valide et continue d’être maintenu dans OpenSSH. La plupart des administrateurs laissent simplement la configuration par défaut, qui privilégie désormais ML-KEM sans supprimer l’ancien algorithme.
Quelle version d’OpenSSH faut-il installer pour bénéficier de ML-KEM ?
OpenSSH 10.0 et les versions ultérieures activent mlkem768x25519-sha256 comme mécanisme hybride par défaut. Les versions antérieures continuent de proposer sntrup761x25519-sha512 comme choix principal.
Cette certification NIST CAVP du 13 octobre 2026 concerne-t-elle les entreprises françaises ?
Pas directement : l’annonce vient d’un fournisseur taïwanais de modules de sécurité. Mais elle illustre une tendance qui concerne tout acheteur européen de matériel cryptographique, à savoir que les fournisseurs internationaux concentrent leurs efforts de certification sur les standards du NIST plutôt que sur des alternatives non normalisées comme NTRU Prime.
HQC peut-il remplacer ML-KEM si une faille y était découverte ?
C’est précisément la raison pour laquelle le NIST a standardisé HQC comme deuxième mécanisme, fondé sur une hypothèse mathématique différente (les codes correcteurs d’erreurs plutôt que les réseaux euclidiens). Si une faiblesse structurelle venait un jour toucher la famille des réseaux euclidiens dont relève ML-KEM, HQC constituerait la solution de repli officiellement reconnue, et non NTRU Prime.