La Commission européenne a fixé une échéance claire : les administrations et les opérateurs critiques doivent engager leur bascule vers la cryptographie post-quantique avant la fin de 2026, avec une protection complète des usages à haut risque exigée pour 2030. Pour les équipes qui doivent choisir aujourd’hui quel mécanisme d’échange de clés déployer, trois options s’affrontent concrètement : X25519, la courbe elliptique classique qui équipe la quasi-totalité du Web depuis une décennie, ML-KEM-768, le standard post-quantique du NIST publié sous FIPS 203, et FrodoKEM-976, l’option conservatrice construite sur des réseaux euclidiens non structurés. Ce comparatif s’appuie sur les tailles de clés publiées par les spécifications officielles, sur quatre bancs d’essai universitaires récents et sur les chiffres d’adoption rapportés par Cloudflare pour trancher laquelle de ces trois briques cryptographiques convient à votre infrastructure. Nous détaillons aussi les coûts d’exploitation réels, le support dans les bibliothèques que vos équipes utilisent déjà, et un guide de migration pas à pas pour ne pas casser la compatibilité de vos clients existants pendant la bascule.
Pourquoi comparer ML-KEM-768, X25519 et FrodoKEM-976 maintenant
Le choix d’un mécanisme d’encapsulation de clés (KEM) n’est plus un exercice théorique réservé aux cryptographes. Depuis que le NIST a publié FIPS 203 en août 2024, standardisant ML-KEM comme dérivé direct de CRYSTALS-Kyber, les éditeurs de navigateurs, les CDN et les fournisseurs de VPN ont commencé à l’intégrer par défaut dans leurs piles TLS 1.3. Cloudflare rapporte que l’échange hybride X25519MLKEM768 protège désormais 52 % du trafic humain sur son réseau, et jusqu’à 70 % du trafic généré par les navigateurs les plus récents, d’après son rapport de transparence relayé par InfoQ en septembre 2026.
Mais ML-KEM n’est pas la seule option post-quantique disponible. L’ANSSI, dans son avis sur la migration vers la cryptographie post-quantique, encourage explicitement l’inclusion de FrodoKEM comme solution conservatrice, et précise qu’un éditeur peut obtenir un visa de sécurité pour un produit qui l’implémente en mode hybride. FrodoKEM repose sur le problème LWE (Learning With Errors) appliqué à des matrices aléatoires non structurées, contrairement à ML-KEM qui utilise des réseaux modulaires structurés de type Module-LWE. Cette différence structurelle a un prix : elle rend FrodoKEM plus lent et plus volumineux, mais elle élimine une classe entière d’attaques algébriques qui pourrait un jour menacer les réseaux structurés. C’est exactement l’arbitrage que ce comparatif met en chiffres.
Ce choix ne concerne pas uniquement les géants du Web. Toute équipe qui gère un VPN d’entreprise, une API exposée publiquement, un firmware embarqué ou un coffre-fort de clés pour la signature de documents doit aujourd’hui répondre à la même question : faut-il basculer directement sur ML-KEM, qui bénéficie du statut officiel de standard NIST, ou vaut-il mieux ajouter une seconde couche de protection avec FrodoKEM, par prudence face à un algorithme encore relativement jeune. La réponse, comme le montrent les sections suivantes, dépend presque entièrement de la durée pendant laquelle vos données doivent rester confidentielles et du matériel sur lequel elles doivent circuler.
X25519 : la référence classique qui équipe déjà votre navigateur
X25519 est un échange Diffie-Hellman sur courbe elliptique, défini par Daniel J. Bernstein et normalisé dans la RFC 7748. Il produit une clé publique de 32 octets et un secret partagé de 32 octets, ce qui en fait l’un des mécanismes les plus compacts jamais déployés à grande échelle. Sa rapidité d’exécution, de l’ordre de quelques dizaines de microsecondes par opération sur un processeur moderne, explique qu’il soit devenu le choix par défaut de TLS 1.3, de Signal, de WireGuard et de la quasi-totalité des gestionnaires SSH modernes.
Le problème n’est pas la sécurité actuelle de X25519 face à un ordinateur classique : le problème du logarithme discret sur courbe elliptique reste hors de portée de toute attaque connue sur du matériel conventionnel. La menace est différente et différée. Un ordinateur quantique suffisamment puissant exécutant l’algorithme de Shor casserait X25519 en un temps polynomial, ce qui rend vulnérable toute donnée chiffrée aujourd’hui et interceptée, puis déchiffrée plus tard une fois la machine quantique disponible. C’est le scénario “store now, decrypt later” que Cloudflare cite comme principal moteur de la migration actuelle, et qui justifie de ne jamais utiliser X25519 seul pour des données dont la confidentialité doit dépasser l’horizon 2030-2035.
X25519 reste par ailleurs le fondement de protocoles de messagerie chiffrée très utilisés, notamment via le protocole X3DH qui équipe Signal pour l’établissement des sessions, ainsi que du mécanisme Noise employé par WireGuard pour les tunnels VPN. Cette omniprésence explique pourquoi la quasi-totalité des travaux de migration post-quantique partent du principe que X25519 restera présent encore de nombreuses années, ne serait-ce que pour assurer la compatibilité avec les clients qui n’auront pas encore basculé vers un échange hybride.
ML-KEM-768 : le standard NIST qui s’impose par défaut
ML-KEM-768 est le niveau de paramètres intermédiaire de la famille ML-KEM, dérivée de CRYSTALS-Kyber et standardisée sous FIPS 203. Sa clé publique pèse 1 184 octets et son texte chiffré 1 088 octets, soit environ 37 fois plus que la clé publique de X25519 et 34 fois plus que son équivalent en taille de message. ML-KEM-768 vise un niveau de sécurité comparable à AES-192, ce qui en fait le choix recommandé par défaut pour le TLS, les VPN et la plupart des usages grand public, tandis que ML-KEM-1024 reste réservé aux cas exigeant un niveau de sécurité maximal et ML-KEM-512, plus compact, cible des usages contraints en ressources.
Sur le plan des performances, un banc d’essai universitaire publié sur arXiv en 2026, portant sur une carte ARM Cortex-M0+ (RP2040) et sur un processeur Intel i7, montre que la génération de clé de ML-KEM-512 et ML-KEM-768 atteint un débit comparable à celui de X25519 sur matériel récent. Un second article, consacré à l’optimisation de TLS 1.3 post-quantique et disponible sur arXiv (2404.13544), chiffre les opérations ML-KEM-1024 à environ 0,051 ms pour la génération de clé et 0,051 ms pour l’encapsulation, des valeurs du même ordre que celles mesurées pour X25519 sur la même plateforme. L’écart se resserre donc fortement sur du matériel serveur moderne, même s’il reste net sur des cibles embarquées moins puissantes.
Les trois niveaux de paramètres de ML-KEM
La famille ML-KEM se décline en trois jeux de paramètres, calibrés sur les mêmes catégories de sécurité que définit le NIST pour l’ensemble de son programme post-quantique. ML-KEM-512 cible un niveau de sécurité comparable à AES-128 et convient aux systèmes très contraints en mémoire ou en bande passante. ML-KEM-768, au centre de ce comparatif, vise un niveau comparable à AES-192 et constitue le choix par défaut documenté pour TLS, les VPN et la plupart des usages grand public. ML-KEM-1024 enfin atteint un niveau comparable à AES-256 et s’adresse aux déploiements qui exigent la marge de sécurité maximale, au prix d’une clé publique et d’un texte chiffré encore plus volumineux que ceux de ML-KEM-768. Cette structure en paliers permet à une organisation de monter en niveau de sécurité sans changer de famille algorithmique ni de bibliothèque, un avantage opérationnel qui pèse dans le choix final à côté des seules performances brutes.
FrodoKEM-976 : la sécurité conservatrice au prix du poids
FrodoKEM n’a pas été retenu par le NIST pour la standardisation finale, mais il reste activement maintenu par ses auteurs académiques et soutenu par plusieurs agences européennes comme option de repli. FrodoKEM-976, le niveau intermédiaire de la famille, publie une clé publique de 15 632 octets et un texte chiffré de 15 792 octets selon la documentation officielle du projet, soit environ 13 fois plus volumineux que ML-KEM-768 et près de 500 fois plus que X25519. Le niveau le plus léger de la famille, FrodoKEM-640, totalise déjà 19 336 octets pour la paire clé publique plus texte chiffré, et le niveau le plus robuste, FrodoKEM-1344, dépasse les 31 000 octets cumulés.
Cette lourdeur a une contrepartie recherchée par les cryptographes les plus prudents : FrodoKEM repose sur le problème LWE appliqué à des matrices générées aléatoirement, sans la structure algébrique additionnelle qu’exploitent ML-KEM ou, plus largement, les schémas basés sur des réseaux modulaires. Un article consacré à l’évaluation de la cryptographie post-quantique pour les réseaux mobiles 6G, publié sur arXiv (2605.06881), mesure que FrodoKEM peut être jusqu’à dix fois plus lent qu’un échange ECDH classique dans certains scénarios, contre un facteur proche de deux pour ML-KEM. Un second banc d’essai, centré sur des environnements de virtualisation légère pour matériel embarqué et publié sous la référence arXiv 2609.23902, confirme que le débit des variantes FrodoKEM-SHAKE décroît fortement à mesure que la dimension des matrices augmente, du niveau 640 jusqu’au niveau 1344.
Pourquoi le NIST n’a pas retenu FrodoKEM comme standard
Le NIST a justifié l’exclusion de FrodoKEM de son standard final principalement par des considérations de performance et de taille de clé, et non par une faiblesse de sécurité identifiée dans l’algorithme lui-même. Pour un organisme qui doit équiper des milliards de connexions TLS quotidiennes, un surcoût réseau de plusieurs dizaines de kilo-octets par poignée de main représente un coût d’infrastructure difficile à justifier face à un algorithme comme ML-KEM qui offre une résistance quantique comparable pour une fraction de ce poids. C’est cette même logique de compromis qui a conduit le NIST à sélectionner ensuite HQC comme second algorithme de KEM standardisé, afin de disposer d’une alternative mathématiquement différente de ML-KEM sans pour autant hériter du poids de FrodoKEM. FrodoKEM reste néanmoins maintenu activement par ses auteurs académiques et continue de progresser dans liboqs et, depuis 2026, nativement dans wolfCrypt.
Tableau comparatif des spécifications techniques
Le tableau suivant réunit les caractéristiques officielles des trois mécanismes, telles que publiées par leurs spécifications respectives (RFC 7748 pour X25519, FIPS 203 pour ML-KEM, documentation FrodoKEM pour FrodoKEM-976). Gardez en tête que ces trois mécanismes ne jouent pas dans la même catégorie historique : X25519 est déployé en production depuis plus de dix ans et a traversé une décennie d’audits publics sans faille structurelle connue, ML-KEM n’a que deux ans d’existence en tant que standard officiel mais hérite de l’analyse académique accumulée sur CRYSTALS-Kyber depuis 2017, et FrodoKEM cumule près d’une décennie de publications scientifiques sans jamais avoir été déployé à une échelle comparable à celle des deux autres.
| Caractéristique | X25519 | ML-KEM-768 | FrodoKEM-976 |
|---|---|---|---|
| Famille mathématique | Courbe elliptique (ECDH) | Réseau modulaire structuré (Module-LWE) | Réseau non structuré (LWE générique) |
| Statut de standardisation | RFC 7748 (IETF) | FIPS 203 (NIST, août 2024) | Candidat NIST round 3, non retenu en standard final |
| Résistance quantique | Non | Oui (niveau de sécurité 3) | Oui (niveau de sécurité 3) |
| Taille clé publique | 32 octets | 1 184 octets | 15 632 octets |
| Taille texte chiffré / secret | 32 octets | 1 088 octets | 15 792 octets |
| Total transmis (aller-retour) | 64 octets | 2 272 octets | 31 424 octets |
| Support OpenSSL 3.x | Natif | Natif depuis 3.5 | Via oqs-provider |
| Support BoringSSL | Natif | Natif | Absent |
| Support wolfSSL | Natif | Natif | Natif depuis wolfCrypt 5.9.4 |
| Recommandation ANSSI | Seul : insuffisant après 2030 | Hybride recommandé par défaut | Hybride, option conservatrice acceptée |
| Usage type recommandé | Hybride avec un KEM post-quantique | TLS, VPN, usages grand public | Archivage long terme, secteurs à très haute exigence |
Benchmarks de performance : ce que mesurent les chercheurs en 2026
Les chiffres de latence varient sensiblement selon le matériel testé, ce qui explique pourquoi il faut croiser plusieurs sources avant de trancher. Sur un processeur Intel i7 récent, les auteurs de l’étude 6G citée plus haut mesurent un débit de génération de clé pour ML-KEM-512 et ML-KEM-768 proche de celui de X25519, les deux mécanismes se situant dans la même fourchette de dizaines de microsecondes par opération. Le même article chiffre l’écart global face à ECDH à un facteur d’environ 2 pour ML-KEM contre un facteur pouvant atteindre 10 pour FrodoKEM, selon le scénario de charge.
Sur du matériel contraint, l’écart se creuse. Le banc d’essai publié sous la référence arXiv 2603.19340, réalisé sur une carte ARM Cortex-M0+ de type RP2040, observe que X25519 conserve un avantage net sur ML-KEM en environnement très contraint en mémoire, notamment à cause de la variance introduite par l’échantillonnage par rejet propre aux schémas à réseaux. Sur un Raspberry Pi 4, cité dans la même famille de travaux, X25519 garde également un avantage de débit mesurable face aux variantes ML-KEM, ce qui pèse sur les choix d’architecture pour l’IoT et les objets connectés à bas coût.
FrodoKEM, enfin, paie son absence de structure algébrique à chaque opération. L’étude sur la virtualisation légère embarquée (arXiv 2609.23902) montre que le débit des variantes FrodoKEM-SHAKE chute progressivement du niveau 640 au niveau 1344, à mesure que la taille des matrices générées augmente, une tendance logique puisque le coût de calcul de FrodoKEM croît directement avec la dimension de la matrice utilisée pour le chiffrement par erreur.
Un point de méthodologie mérite d’être signalé : ces quatre bancs d’essai ne mesurent pas exactement les mêmes grandeurs ni sur le même matériel, ce qui explique les écarts de facteur observés entre les études. Un chiffre de performance post-quantique n’a de sens que rapporté à son contexte de mesure précis, processeur, compilateur et version de bibliothèque, raison pour laquelle ce comparatif cite systématiquement la source de chaque chiffre plutôt que de présenter un classement unique et universel.
Impact sur la bande passante et les connexions TLS
La taille des messages échangés a des conséquences directes sur l’expérience utilisateur, en particulier sur les réseaux mobiles ou les liaisons satellite à latence élevée. Un handshake TLS 1.3 hybride X25519+ML-KEM-768 ajoute environ 2 272 octets par rapport à un handshake X25519 seul, un surcoût que Cloudflare qualifie de négligeable sur une connexion fixe mais mesurable sur une connexion mobile en 3G ou sur un lien satellite à forte latence. Avec FrodoKEM-976, le même calcul grimpe à plus de 31 000 octets supplémentaires par poignée de main, soit l’équivalent d’un petit fichier image transféré à chaque connexion TLS.
Cloudflare a observé que le taux de connexions post-quantiques nécessitant une relance complète du handshake, le “HelloRetryRequest”, est passé de 0 % à plus de 99,2 % de connexions réussies du premier coup côté serveurs d’origine ayant migré, preuve que l’écosystème TLS a eu le temps de s’adapter aux paquets plus volumineux générés par ML-KEM. Pour FrodoKEM, dont le volume de données dépasse largement la taille habituelle d’un paquet MTU standard de 1 500 octets, la fragmentation devient systématique, ce qui ajoute de la latence réseau même lorsque le calcul cryptographique lui-même reste rapide.
Sur un réseau mobile en 4G ou 5G, l’effet reste généralement absorbé sans dégradation perceptible, car la latence du lien radio domine largement le temps de transmission d’un paquet de quelques kilo-octets supplémentaires. Sur une liaison satellite bas débit, un lien LoRaWAN pour l’IoT étendu, ou un réseau 2G/3G encore actif dans certaines zones rurales, le calcul change radicalement : chaque kilo-octet transmis compte, et c’est précisément dans ce type de contexte que la légèreté de X25519 ou de ML-KEM-512 prend l’avantage sur FrodoKEM, quelle que soit la marge de sécurité mathématique supplémentaire que ce dernier apporte.
Support dans les bibliothèques cryptographiques
Le choix d’un algorithme dépend aussi de sa disponibilité réelle dans les bibliothèques que vos équipes utilisent déjà. OpenSSL 3.x intègre ML-KEM-512, 768 et 1024 nativement depuis la branche 3.5, tandis que FrodoKEM, HQC et BIKE restent accessibles via le module externe oqs-provider, adossé au projet Open Quantum Safe (liboqs). BoringSSL, la bibliothèque de Google utilisée par Chrome, prend en charge ML-KEM mais n’implémente ni FrodoKEM, ni HQC, ni BIKE, un choix délibéré de Google qui privilégie un nombre restreint d’algorithmes jugés matures.
wolfSSL a pris une direction différente en 2026 : la version 5.9.4 de wolfCrypt intègre désormais FrodoKEM nativement, avec du code en C et en assembleur optimisé pour x86_64, AArch64, AArch32 et Thumb2, ainsi que des clés ASN.1 et des certificats X.509 dédiés. L’éditeur a par ailleurs abandonné sa dépendance à liboqs pour tous ses algorithmes post-quantiques, ce qui réduit la surface de dépendances externes à auditer pour les équipes de sécurité travaillant sur des systèmes embarqués ou automobiles.
Botan, la bibliothèque C++ portée par Jack Lloyd et largement utilisée dans des projets européens de cryptographie embarquée, intègre ML-KEM nativement et propose un support partiel de FrodoKEM selon la version. Pour les équipes travaillant en Python, le paquet cryptography et les bindings liboqs-python exposent également ML-KEM, tandis que FrodoKEM reste accessible mais moins documenté dans cet écosystème, ce qui en pratique pousse davantage de projets open source vers ML-KEM par simple facilité d’intégration, indépendamment des arguments de sécurité purement mathématiques.
| Bibliothèque | X25519 | ML-KEM-768 | FrodoKEM-976 |
|---|---|---|---|
| OpenSSL 3.5+ | Natif | Natif | Via oqs-provider |
| BoringSSL | Natif | Natif | Non disponible |
| wolfSSL / wolfCrypt 5.9.4 | Natif | Natif | Natif |
| liboqs (Open Quantum Safe) | N/A | Natif, optimisé AVX2/AArch64 | Natif |
| Botan | Natif | Natif | Partiel |
Tableau de coûts : HSM et gestion des clés en production
Déployer ces mécanismes à l’échelle d’une entreprise implique souvent de passer par un module matériel de sécurité (HSM) ou un service de gestion de clés managé. Le choix de l’algorithme influe peu sur la facture tant que le fournisseur supporte l’opération demandée, mais la taille des clés FrodoKEM peut faire sortir certains services managés de leurs limites de stockage par défaut. Voici les tarifs publics constatés pour les options les plus courantes.
| Service | Modèle tarifaire | Coût indicatif | Compatibilité PQC |
|---|---|---|---|
| AWS CloudHSM | À l’heure, par instance | Environ 1,60 $/heure, soit ~1 168 $/mois en continu | Via intégration cliente OpenSSL/oqs-provider |
| Azure Managed HSM (pool Standard B1) | À l’heure, par pool | Environ 3,20 $/heure, soit plus de 2 300 $/mois | Clés HSM premium facturées 1 à 5 $/clé/mois en sus |
| Google Cloud HSM | Par version de clé + par opération | Environ 1 à 2 $/version de clé/mois, plus 0,03 à 0,15 $/opération | Modèle à l’usage, adapté aux faibles volumes |
| Thales Luna 8 (on-premise) | Licence matérielle | Sur devis | Support post-quantique natif annoncé par Thales |
À volume constant d’opérations cryptographiques, le modèle Google Cloud facturé à l’usage devient généralement le plus économique pour les charges faibles ou irrégulières, tandis que les pools dédiés AWS et Azure se justifient surtout au-delà de plusieurs millions d’opérations mensuelles, où le coût fixe horaire finit par être amorti. Aucun des trois fournisseurs cloud ne facture différemment selon l’algorithme post-quantique choisi : le surcoût de FrodoKEM se paie en bande passante réseau et en stockage de clés, pas en frais de service HSM.
Exemples réels de déploiement en 2026
Cloudflare a été l’un des premiers grands opérateurs à activer X25519MLKEM768 par défaut sur son réseau de périphérie, et rapporte que le support côté serveurs d’origine est passé de 0,5 % en 2023 à 12,8 % aujourd’hui, un rythme de croissance qu’elle attribue directement à l’intégration de ML-KEM dans les versions récentes de Chrome, Firefox, OpenSSL et Go.
En France, la Banque de France a choisi de protéger sa plateforme de collecte réglementaire OneGate avec une combinaison FIPS 203 et FIPS 204, c’est-à-dire ML-KEM pour l’échange de clés et ML-DSA pour la signature, plutôt que d’intégrer FrodoKEM, jugé trop lourd pour une plateforme à fort trafic transactionnel.
Thales a de son côté positionné sa gamme Luna 8 comme la première famille de HSM à annoncer un support post-quantique natif, en ciblant explicitement les secteurs bancaire et étatique où le volume de clés gérées justifie un matériel dédié plutôt qu’un service cloud mutualisé.
wolfSSL a orienté son développement de FrodoKEM vers l’automobile et l’industriel, où les contraintes de certification à très long cycle de vie, parfois supérieures à quinze ans pour un calculateur embarqué, rendent la prudence mathématique de FrodoKEM plus attractive que la performance brute de ML-KEM.
Enfin, le projet Tor a entamé sa propre migration post-quantique, documentée dans la littérature académique, en évaluant à la fois ML-KEM et des alternatives plus conservatrices pour protéger les circuits de son réseau d’anonymisation contre la menace de déchiffrement différé, un cas d’usage où la discrétion du trafic peut peser autant que sa rapidité.
Ces cinq cas illustrent une tendance de fond : les opérateurs à très fort volume de trafic (Cloudflare, Banque de France) convergent vers ML-KEM pour son équilibre performance-sécurité, tandis que les secteurs à cycle de vie long ou à exigence réglementaire maximale (automobile via wolfSSL, HSM bancaires via Thales) gardent FrodoKEM en réserve comme filet de sécurité mathématique plutôt que comme choix par défaut.
Quel algorithme choisir selon votre cas d’usage
Le bon choix dépend presque toujours du contexte de déploiement plutôt que d’un classement universel. Voici cinq situations concrètes et la réponse qui s’en dégage à partir des données réunies dans ce comparatif.
- Site web public ou API grand public : hybride X25519+ML-KEM-768, le choix adopté par Cloudflare et la quasi-totalité des CDN, pour un surcoût de bande passante négligeable face au gain de protection contre le déchiffrement différé.
- VPN d’entreprise ou liaison site à site : hybride ML-KEM-768, en s’appuyant sur le support natif désormais présent dans OpenSSL 3.5 et wolfSSL, sans justification à utiliser FrodoKEM sauf exigence contractuelle spécifique.
- Objets connectés ou capteurs IoT à mémoire très limitée : X25519 seul reste parfois inévitable à court terme faute de ressources, mais doit être complété dès que possible par ML-KEM-512, le niveau le plus compact de la famille, plutôt que par FrodoKEM dont la taille de clé dépasse souvent la RAM disponible.
- Archivage réglementaire ou données à confidentialité supérieure à 20 ans : FrodoKEM-976 ou 1344 en hybride, conformément à la logique de défense en profondeur promue par l’ANSSI pour les données dont la valeur reste critique bien après 2040.
- Secteur bancaire et HSM dédiés : ML-KEM-768 pour les flux à fort volume comme les transactions temps réel, et FrodoKEM en option de secours documentée pour les processus de signature de clés racines, où la fréquence d’exécution est faible et la marge de sécurité prime sur la vitesse.
Guide de migration : passer de X25519 à un échange hybride post-quantique
La migration ne consiste jamais à remplacer X25519 brutalement par un KEM post-quantique seul : la quasi-totalité des recommandations européennes, dont celles de l’ANSSI et du BSI, imposent un mode hybride qui combine l’algorithme classique et l’algorithme post-quantique, de sorte qu’un attaquant doive casser les deux mécanismes simultanément pour compromettre la session.
Le piège le plus fréquent observé par les équipes qui migrent en 2026 n’est pas le choix de l’algorithme lui-même, mais la sous-estimation de l’impact sur les équipements réseau intermédiaires, les anciennes versions de clients TLS et les processus de certification déjà engagés. Les neuf étapes suivantes reprennent l’ordre dans lequel les déploiements réussis ont généralement procédé, de l’audit initial jusqu’à la préparation du cycle de migration suivant.
- Cartographier les flux chiffrés existants. Identifiez où X25519 ou RSA sont utilisés aujourd’hui : TLS entrant, VPN, API internes, signatures de firmware.
- Classer les données par horizon de confidentialité. Une donnée qui doit rester confidentielle après 2035 est prioritaire, conformément à la logique du scénario “store now, decrypt later”.
- Mettre à jour la pile TLS. Passez à OpenSSL 3.5 ou une version récente de wolfSSL qui supporte nativement X25519MLKEM768.
- Activer l’hybride côté serveur sans désactiver le classique. Conservez X25519 en repli pour la compatibilité avec les clients qui ne supportent pas encore ML-KEM.
- Tester l’impact sur la taille des paquets et la fragmentation MTU. Un handshake plus volumineux peut déclencher des middleboxes réseau mal configurées ; validez en environnement de préproduction.
- Évaluer FrodoKEM pour les cas à très longue durée de vie. Si vos données doivent rester confidentielles plusieurs décennies, ajoutez une couche FrodoKEM pour les opérations à faible fréquence comme la signature de clés racines.
- Auditer les dépendances aux bibliothèques tierces. Vérifiez si votre fournisseur HSM ou votre bibliothèque TLS repose sur liboqs, et anticipez une éventuelle transition vers une implémentation native comme l’a fait wolfSSL.
- Documenter la conformité réglementaire. Conservez une preuve de l’hybridation pour répondre aux exigences de certification, l’ANSSI ayant cessé en juin 2026 de délivrer des certifications sans composante post-quantique.
- Planifier un second cycle de migration. Le NIST a par ailleurs retenu HQC comme second algorithme de KEM standardisé, ce qui signifie que votre architecture devra rester suffisamment modulaire pour accueillir un nouvel algorithme sans réécriture complète.
Avantages et inconvénients de chaque mécanisme
X25519 reste imbattable en légèreté et en rapidité, avec un support universel dans tous les navigateurs et bibliothèques existants, mais il est condamné à terme par l’informatique quantique et ne doit plus jamais être déployé seul pour des données à conserver après 2030. ML-KEM-768 offre le meilleur compromis actuel entre sécurité post-quantique, taille de message raisonnable et performance proche du classique sur du matériel serveur moderne, au prix d’un support encore incomplet sur le matériel très contraint et d’une dépendance à un algorithme plus récent, donc moins éprouvé que les courbes elliptiques. FrodoKEM-976 apporte la marge de sécurité mathématique la plus conservatrice du marché, sans aucune hypothèse structurelle supplémentaire exploitable par un futur algorithme d’attaque, mais son poids réseau et son absence de support dans BoringSSL en limitent l’usage aux scénarios où la bande passante n’est pas la contrainte dominante.
Un autre inconvénient souvent sous-estimé de FrodoKEM concerne le stockage. Une infrastructure qui gère des millions de paires de clés voit sa base de données de clés publiques grossir d’un facteur supérieur à dix si elle bascule entièrement vers FrodoKEM-976 plutôt que ML-KEM-768, ce qui a un impact direct sur les coûts de sauvegarde, de réplication et de temps de restauration en cas d’incident. Pour ML-KEM, cet impact reste contenu puisque la clé publique ne dépasse pas 1 184 octets, un ordre de grandeur proche de celui d’un certificat RSA-2048 classique que la plupart des infrastructures savent déjà gérer à grande échelle.
Verdict : quel KEM pour quelle échéance
Pour la grande majorité des équipes qui doivent se mettre en conformité avec l’échéance européenne de fin 2026, l’hybride X25519+ML-KEM-768 est le choix par défaut le plus justifié par les données : il est déjà supporté nativement par OpenSSL, BoringSSL et wolfSSL, il protège plus de la moitié du trafic TLS mondial selon Cloudflare, et ses performances se rapprochent de celles de X25519 seul sur du matériel serveur récent, avec un surcoût de 2 272 octets par connexion jugé négligeable à l’échelle d’Internet. FrodoKEM-976 n’est pas un concurrent direct de ML-KEM pour un usage généraliste : c’est une police d’assurance mathématique, à réserver aux systèmes dont l’horizon de confidentialité dépasse plusieurs décennies ou aux secteurs régulés qui exigent explicitement une alternative structurellement différente de Module-LWE, comme le permet déjà l’avis de l’ANSSI. X25519 seul, enfin, ne doit plus figurer dans aucune feuille de route de sécurité pour une nouvelle infrastructure déployée en 2026 : son rôle se limite désormais à la composante classique d’un montage hybride.
En résumé chiffré : si votre priorité est la compatibilité et la performance immédiate, choisissez l’hybride X25519+ML-KEM-768, déjà présent dans OpenSSL 3.5, BoringSSL et wolfSSL. Si votre priorité est la marge de sécurité mathématique sur plusieurs décennies et que votre budget réseau le permet, superposez FrodoKEM-976 sur les opérations critiques à faible fréquence. Et si votre infrastructure reste aujourd’hui limitée à X25519 seul, traitez cela comme une dette technique à résorber avant l’échéance 2030 fixée par la feuille de route européenne, pas comme une option à conserver indéfiniment.
Questions fréquentes
ML-KEM-768 remplace-t-il complètement X25519 ?
Non. Les recommandations européennes, dont celles de l’ANSSI, imposent un mode hybride qui combine les deux algorithmes plutôt que de remplacer purement et simplement X25519 par ML-KEM-768.
FrodoKEM est-il plus sûr que ML-KEM parce qu’il n’a pas été standardisé ?
Le NIST n’a pas retenu FrodoKEM pour la standardisation finale principalement pour des raisons de performance et de taille de clé, pas pour un défaut de sécurité identifié. Plusieurs agences européennes continuent de le recommander comme option conservatrice en complément de ML-KEM.
Pourquoi FrodoKEM n’est-il pas disponible dans BoringSSL ?
Google a choisi de limiter le nombre d’algorithmes post-quantiques intégrés nativement à BoringSSL pour réduire la surface d’audit, en priorisant ML-KEM, déjà standardisé par le NIST sous FIPS 203.
Quel est l’impact de ML-KEM sur la latence d’une connexion TLS classique ?
Sur un matériel serveur moderne, l’écart de latence entre X25519 et ML-KEM-768 reste de l’ordre de quelques dizaines de microsecondes par opération, un impact généralement imperceptible pour l’utilisateur final.
FrodoKEM peut-il poser un problème de fragmentation réseau ?
Oui. Un échange FrodoKEM-976 dépasse largement la taille d’un paquet MTU standard de 1 500 octets, ce qui entraîne une fragmentation systématique et peut ajouter de la latence sur certains réseaux.
Faut-il utiliser ML-KEM-512, 768 ou 1024 ?
ML-KEM-768 est le niveau recommandé par défaut pour la plupart des usages TLS et VPN. ML-KEM-512 convient aux environnements très contraints en ressources, tandis que ML-KEM-1024 vise les cas exigeant le niveau de sécurité maximal.
Les HSM cloud facturent-ils différemment selon l’algorithme post-quantique utilisé ?
Non, les tarifs d’AWS CloudHSM, Azure Managed HSM et Google Cloud HSM dépendent du temps d’utilisation ou du nombre d’opérations, pas du choix spécifique entre ML-KEM et FrodoKEM. Le principal surcoût de FrodoKEM se situe dans le stockage des clés et la bande passante réseau.
Quand toutes les infrastructures critiques devront-elles avoir migré ?
Selon la feuille de route coordonnée adoptée par les États membres de l’Union européenne en juin 2025, les cas d’usage à haut risque doivent être protégés par des mécanismes post-quantiques au plus tard en 2030, avec un objectif plus large de conversion visant 2035.
Peut-on combiner ML-KEM-768 et FrodoKEM-976 dans le même système ?
Oui, et certains déploiements à très haute exigence le font déjà en pratique : ML-KEM gère les échanges à fort volume comme les sessions TLS courantes, tandis que FrodoKEM est réservé aux opérations rares et critiques comme la signature ou le renouvellement des clés racines, où le coût réseau supplémentaire importe peu.
wolfSSL, OpenSSL ou BoringSSL : laquelle choisir pour démarrer une migration post-quantique ?
Le choix dépend de votre plateforme cible. OpenSSL 3.5 convient à la majorité des serveurs Linux généralistes, wolfSSL s’impose pour l’embarqué et l’automobile grâce à son support natif de FrodoKEM, et BoringSSL reste pertinent uniquement si votre pile dépend déjà de Chromium ou de l’écosystème Google, puisqu’elle ne couvre pas FrodoKEM.
