L'ANSSI et la cryptographie post-quantique hybride : ce qu'attend la France

L'ANSSI, l'Agence nationale de la sécurité des systèmes d'information, ne demande pas aux organisations de remplacer la cryptographie classique par la cryptographie post-quantique. Elle demande les deux à la fois. L'hybridation, c'est-à-dire un établissement de clé dont la clé de session dépend à la fois d'un algorithme classique et d'un mécanisme d'encapsulation de clé (KEM) post-quantique, est obligatoire dans le périmètre que l'ANSSI réglemente. En dehors de ce périmètre, l'ANSSI publie des recommandations, et elle indique que ces recommandations ne constituent pas encore des obligations réglementaires.

Ce que l'ANSSI entend par hybridation

Une poignée de main hybride effectue deux établissements de clé et combine les deux secrets partagés dans la clé de session. Un attaquant doit casser les deux pour récupérer le trafic. Cette conception répond à deux préoccupations distinctes à la fois. La moitié classique conserve les garanties de deux décennies d'analyse et d'implémentations bien auditées, comme X25519 ou ECDH sur les courbes NIST. La moitié post-quantique, en pratique ML-KEM tel que normalisé par le NIST dans FIPS 203 le 13 août 2024 (csrc.nist.gov), supprime l'exposition au risque « récolter maintenant, déchiffrer plus tard » (harvest now, decrypt later, HNDL), dans lequel un attaquant enregistre aujourd'hui du trafic chiffré pour le déchiffrer des années plus tard. Le trafic enregistré n'est protégé que par l'échange de clés : c'est pourquoi l'échange de clés migre en premier, les signatures et les certificats pouvant suivre.

Sur le réseau, l'hybridation n'est qu'un groupe nommé. L'IANA a enregistré X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) et SecP384r1MLKEM1024 (0x11ED) pour TLS 1.3 (paramètres TLS de l'IANA), et la RFC 10024 (août 2026) spécifie des mécanismes d'accord de clé hybrides post-quantiques et traditionnels pour TLS 1.3 (rfc-editor.org). Les versions actuelles de Chrome, Edge et Firefox proposent X25519MLKEM768 par défaut : son activation côté serveur est donc normalement invisible pour les utilisateurs. Pour SSH, OpenSSH a ajouté mlkem768x25519-sha256 dans la version 9.9 (19 septembre 2024) et en a fait l'accord de clé par défaut dans la version 10.0 (9 avril 2025), la version 10.1 (6 octobre 2025) émettant un avertissement lorsqu'une connexion négocie un accord de clé non post-quantique (notes de version d'OpenSSH).

Où l'hybridation est obligatoire, et où elle relève du conseil

L'exigence de l'ANSSI est contraignante dans le périmètre qu'elle administre, tel que décrit dans sa FAQ post-quantique (cyber.gouv.fr) :

• Qualification de produits : les produits de sécurité qui détiennent ou sollicitent une qualification de l'ANSSI.
• Diffusion Restreinte (DR) : les systèmes d'information traitant des informations de niveau Diffusion Restreinte et les produits qui les protègent.
• SAIV et SIIV : les secteurs d'activités d'importance vitale et leurs systèmes d'information d'importance vitale.

Partout ailleurs, la position est une recommandation. Une entreprise française qui ne vend pas de produits qualifiés, ne traite pas d'informations Diffusion Restreinte et n'est pas un opérateur d'importance vitale n'est pas liée aujourd'hui par la doctrine post-quantique de l'ANSSI, et l'ANSSI le dit elle-même. Cette nuance compte lorsque vous rédigez une feuille de route : ne présentez pas à votre conseil d'administration les orientations de l'ANSSI comme une échéance légale lorsqu'elles n'en sont pas une. Vous pouvez néanmoins être soumis à d'autres textes qui ne disent rien de l'informatique quantique mais tout du changement d'algorithmes : DORA, à l'article 6 du règlement délégué (UE) 2024/1774 de la Commission, exige une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions pour mettre à jour ou changer la technologie cryptographique en fonction de l'évolution de la cryptanalyse (EUR-Lex), et NIS2 Article 21(2)(h) exige des politiques et procédures relatives à l'utilisation de la cryptographie (EUR-Lex). Notre lecture, présentée comme une interprétation et non comme une exigence de l'un ou l'autre texte, est qu'un plan d'échange de clés hybride constitue un moyen crédible de montrer qu'une telle politique est vivante et non décorative. Cet article informe sur des orientations publiées et ne constitue pas un conseil juridique.

Les dates fixées par l'ANSSI

Deux signaux orientent les achats en France. L'ANSSI vise à exiger la cryptographie post-quantique pour les produits entrant en qualification à partir de 2027, et elle considère qu'après 2030 il ne sera plus raisonnable d'acheter des produits dépourvus de cryptographie post-quantique. Le second point est une recommandation, pas une interdiction, mais c'est une indication forte pour tout contrat pluriannuel signé aujourd'hui. L'historique daté complet est tenu à jour sur notre page consacrée à la doctrine de l'ANSSI.

Ces dates sont proches du calendrier européen : la feuille de route de mise en œuvre coordonnée de l'UE v1.1 (Coordinated Implementation Roadmap), publiée le 23 juin 2025, prévoit un inventaire cryptographique et des feuilles de route nationales d'ici fin 2026, la migration des cas d'usage à risque élevé d'ici fin 2030 et celle des cas à risque moyen d'ici fin 2035 (Commission européenne). Cette feuille de route constitue une orientation coordonnée à destination des États membres, et non un règlement contraignant pour les entreprises ; notre page sur la feuille de route recense les jalons avec leur statut. Le guide technique TR-02102-1 du BSI allemand va dans le même sens : la version 2026-01 recommande l'accord de clé hybride post-quantique et ne recommande l'accord de clé classique seul que jusqu'à fin 2031, ou fin 2030 pour les besoins de protection très élevés.

Des niveaux de sécurité plus élevés lorsque c'est possible

ML-KEM comporte trois jeux de paramètres : ML-KEM-512, ML-KEM-768 et ML-KEM-1024. L'ANSSI exprime une préférence pour les niveaux de sécurité les plus élevés lorsque les performances et l'interopérabilité le permettent. En pratique, pour les services web publics, cela signifie X25519MLKEM768 comme socle interopérable, puisque les navigateurs le proposent aujourd'hui, et SecP384r1MLKEM1024 réservé aux liaisons dont vous maîtrisez les deux extrémités et pour lesquelles les octets supplémentaires de la poignée de main sont acceptables. La NSA adopte une orientation comparable dans un autre cadre : CNSA 2.0, qui s'applique uniquement aux National Security Systems américains, spécifie ML-KEM-1024, ML-DSA-87 et AES-256.

Deux mises en garde. Augmenter le jeu de paramètres ne justifie jamais d'abandonner la moitié classique : un groupe ML-KEM pur tel que MLKEM768 ne satisfait aucune exigence d'hybridation. Et les groupes Kyber antérieurs à la norme, en particulier X25519Kyber768Draft00 (codepoint 0x6399), sont obsolètes et doivent être remplacés par les groupes ML-KEM plutôt que conservés comme solution de repli.

Que déployer, et comment le vérifier

Vérifier ce que vous négociez aujourd'hui

Commencez en lecture seule. Les groupes ML-KEM dans OpenSSL nécessitent OpenSSL 3.5 ou une version ultérieure : vérifiez donc d'abord la version, puis interrogez un serveur sur un groupe précis.

openssl version

openssl s_client -connect example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i 'Negotiated TLS1.3 group'

ssh -Q kex | grep mlkem

Si la ligne du groupe revient vide ou se rabat sur X25519, le serveur n'a aucun groupe hybride activé. Côté serveur, placez le groupe hybride en premier et un groupe classique ensuite, afin qu'un client ancien puisse toujours se connecter, et testez en préproduction avant la production. Avec nginx compilé contre OpenSSL 3.5 ou une version ultérieure, la directive est :

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

La syntaxe diffère selon les serveurs web et selon les versions : suivez le détail par serveur dans notre guide pour activer ML-KEM sur nginx, Apache, HAProxy et Caddy plutôt que de copier une même directive partout.

Les preuves à conserver

Que les règles de l'ANSSI s'appliquent à vous ou non, les éléments qu'un auditeur ou un client du secteur public vous demandera sont les mêmes :

Pour la deuxième ligne, consignez le nom du groupe, et non un simple résultat conforme ou non conforme : un X25519MLKEM768 négocié est un fait qu'un auditeur peut revérifier.

Prochaine étape : mesurer avant de planifier

La doctrine de l'ANSSI se lit en un après-midi. Savoir lesquels de vos propres services proposent déjà un groupe hybride exige une mesure. Vous pouvez analyser votre domaine avec PQC Status gratuitement pour connaître les versions de TLS, les suites de chiffrement, la chaîne de certificats et savoir si un groupe hybride ML-KEM est négocié. Une analyse décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité. Utilisez-la comme première ligne de l'inventaire, puis activez X25519MLKEM768 sur vos points d'accès publics avec un repli classique, et ajoutez une exigence d'échange de clés hybride au prochain contrat que vous renouvelez, en anticipation du signal d'achat de l'après-2030.