Cryptographie post-quantique : ce qui change

La cryptographie post-quantique désigne les algorithmes conçus pour résister à un futur ordinateur quantique capable de casser RSA, Diffie-Hellman et les courbes elliptiques. Ces algorithmes fonctionnent sur les ordinateurs actuels ; ils sont normalisés depuis 2024 et déjà utilisés, en combinaison avec les algorithmes classiques, dans les connexions HTTPS et SSH. Ce chapitre explique ce que menacerait un ordinateur quantique, pourquoi il faut agir dès maintenant, quels sont les nouveaux standards et ce que recommande l'ANSSI. C'est un sujet de veille technologique, idéal pour ton E5, plus qu'une notion d'E7.

Ce qu'un ordinateur quantique changerait

Un ordinateur quantique ne calcule pas « plus vite » en général : il résout plus vite certains problèmes précis. Deux algorithmes concernent la cryptographie :

• l'algorithme de Shor (1994) factorise les grands nombres et calcule les logarithmes discrets en un temps raisonnable. Il casserait RSA, Diffie-Hellman et la cryptographie sur courbes elliptiques, c'est-à-dire tout l'asymétrique actuel ;
• l'algorithme de Grover (1996) accélère la recherche exhaustive : il réduirait en théorie de moitié le nombre de bits de sécurité d'une clé symétrique ou d'une fonction de hachage.

Le qubit et l'algorithme de Shor, en bref. Un bit classique vaut 0 ou 1. Un qubit peut se trouver dans une superposition des deux états, et plusieurs qubits peuvent être intriqués : un calcul agit alors sur toutes les combinaisons à la fois. Ce n'est pas une recherche exhaustive gratuite, car la mesure finale ne donne qu'un seul résultat ; il faut un algorithme qui fasse ressortir la bonne réponse. Shor en fournit un pour la factorisation : il ramène le problème à la recherche de la période d'une fonction, qu'une transformée de Fourier quantique révèle efficacement, et de cette période on déduit les facteurs premiers de n, donc la clé privée RSA. Le même principe s'applique au logarithme discret, sur lequel reposent Diffie-Hellman et les courbes elliptiques.

Personne ne sait quand un tel ordinateur existera, ni s'il existera : les machines actuelles comptent trop peu de qubits, et trop instables, pour menacer une clé RSA réelle. Les estimations parlent de la décennie 2030 ou au-delà, avec une forte incertitude. Les ressources nécessaires baissent pourtant à mesure que les algorithmes s'améliorent : en mai 2025, le chercheur Craig Gidney (Google) a estimé qu'une clé RSA de 2 048 bits pourrait être factorisée en moins d'une semaine avec moins d'un million de qubits bruités, quand les estimations de 2019 en demandaient vingt millions.

« Récolter maintenant, déchiffrer plus tard »

Pourquoi s'en soucier aujourd'hui ? Parce qu'un attaquant patient peut enregistrer dès maintenant des communications chiffrées (des échanges diplomatiques, des secrets industriels, des données de santé) et attendre de disposer d'un ordinateur quantique pour les déchiffrer. Si une donnée doit rester confidentielle quinze ans, et qu'un ordinateur quantique apparaît dans dix ans, elle est déjà menacée.

Les résultats d'analyses du laboratoire Hélianthe en sont un bon exemple : une donnée de santé reste sensible toute la vie du patient. Pour elles, l'échange de clés des connexions qui les transportent devrait dès maintenant être post-quantique. La signature, elle, est moins urgente : une signature ne peut pas être falsifiée rétroactivement, il suffit de changer d'algorithme avant l'arrivée de la menace (sauf pour les signatures qui doivent rester vérifiables très longtemps, comme celles des racines de PKI ou des micrologiciels).

Les nouveaux standards : ML-KEM, ML-DSA, SLH-DSA

Le NIST américain a mené de 2016 à 2024 un concours public, comme pour AES. En août 2024, il a publié trois normes :

En mars 2025, le NIST a retenu HQC, fondé sur les codes correcteurs d'erreurs, comme second mécanisme d'encapsulation de secours, et une norme de signature fondée sur Falcon (FN-DSA) est en préparation. Des chercheurs français figurent parmi les auteurs de plusieurs de ces algorithmes, dont HQC et Falcon.

Ces algorithmes ont un coût : des clés et des messages plus gros. Une clé publique ML-KEM-768 fait 1 184 octets, contre 32 pour X25519 ; une signature ML-DSA-65 fait 3 309 octets, contre 64 pour Ed25519. Rien d'insurmontable pour un ordinateur, mais un vrai sujet pour les objets connectés et les protocoles contraints.

L'hybridation : la position de l'ANSSI

Ces algorithmes sont récents : ils n'ont pas des décennies d'analyse derrière eux, et un candidat du concours du NIST (SIKE) a été cassé en 2022 sur un ordinateur portable ordinaire. L'ANSSI en tire une position nette, inscrite dans son guide de mars 2026 sur les mécanismes cryptographiques : un produit qui vise une sécurité post-quantique doit rester au moins aussi sûr qu'aujourd'hui face aux attaques classiques. Comme aucun mécanisme ne garantit encore les deux à la fois, il faut hybrider : combiner un algorithme classique éprouvé et un algorithme post-quantique, de sorte que l'attaquant doive casser les deux.

Concrètement, selon ce guide :

• ML-KEM utilisé seul n'est pas conforme ; il l'est s'il est hybridé avec un mécanisme classique, et le niveau ML-KEM-768 est préférable à ML-KEM-512 ;
• pour les signatures, on peut concaténer une signature classique et une signature post-quantique, la signature hybride n'étant valide que si les deux le sont ; les signatures fondées uniquement sur le hachage, comme SLH-DSA, peuvent être utilisées sans hybridation ;
• pour le symétrique et le hachage, l'ANSSI recommande, quand une sécurité post-quantique est visée, des clés d'au moins 192 bits et des empreintes d'au moins 384 bits.

Déjà dans ton navigateur : X25519MLKEM768

L'hybridation n'est pas un projet lointain. Le groupe d'échange de clés X25519MLKEM768, qui combine X25519 (classique) et ML-KEM-768 (post-quantique), est activé par défaut dans les principaux navigateurs (Chrome, Edge, Firefox), chez de grands hébergeurs et réseaux de diffusion, et dans OpenSSL depuis la version 3.5 (avril 2025). OpenSSH l'utilise aussi par défaut depuis sa version 10.0 (avril 2025), sous le nom mlkem768x25519-sha256.

Tu peux le constater toi-même :

echo | openssl s_client -connect www.cloudflare.com:443 -brief 2>&1 | grep -i group
# Negotiated TLS1.3 group: X25519MLKEM768

openssl list -kem-algorithms       # liste ML-KEM-512, ML-KEM-768, ML-KEM-1024 et les hybrides
ssh -Q kex | grep mlkem            # côté OpenSSH : mlkem768x25519-sha256

Dans la poignée de main TLS 1.3 (chapitre 9), seule la part de clé du ClientHello et du ServerHello change : elle contient à la fois une part X25519 et une part ML-KEM. Le secret de session est dérivé des deux.

Se préparer : inventaire et agilité cryptographique

Pour une organisation, la migration commence par des tâches très concrètes, qui relèvent du travail d'un technicien :

1. Inventorier la cryptographie utilisée : quels protocoles, quelles versions de bibliothèques, quels certificats (algorithme, taille, échéance), quelles données chiffrées et pour combien de temps.
2. Prioriser les données à longue durée de confidentialité (santé, propriété industrielle, archives) et les flux qui les transportent.
3. Mettre à jour : des versions récentes d'OpenSSL, d'OpenSSH, des navigateurs, des serveurs web et des VPN apportent l'hybride sans effort ; les équipements anciens qui ne seront jamais mis à jour sont à planifier pour remplacement.
4. Viser l'agilité cryptographique : des applications où l'algorithme est un paramètre de configuration, pas une constante codée en dur, pour pouvoir changer d'algorithme sans tout réécrire.
5. Exiger le post-quantique dans les achats de produits de sécurité (VPN, HSM, PKI) qui protégeront des données au-delà de 2030.

Un exemple d'inventaire : le laboratoire Hélianthe. Le service informatique recense les flux et les données chiffrées, puis classe chaque ligne selon la durée pendant laquelle la donnée doit rester confidentielle :

Les deux priorités hautes sont les échanges de clés qui transportent des données de santé : c'est exactement la menace « récolter maintenant, déchiffrer plus tard ». Les signatures et les sessions courtes peuvent attendre.

À l'E7 et à l'E5

Aucun des sujets d'E7 vérifiés de 2022 à 2026 n'a interrogé la cryptographie post-quantique. En revanche, le sujet se prête parfaitement à la veille technologique que tu présentes à l'E5 (méthode de la veille) : il évolue chaque année (nouvelles normes, prises de position de l'ANSSI, déploiement dans les logiciels), il touche les deux options et il se raccroche à des actions concrètes (inventaire, mise à jour, configuration). À l'E7, il peut servir d'argument : justifier le choix d'AES-256 plutôt qu'AES-128 pour des archives de santé, ou celui d'un VPN qui prend en charge l'échange hybride.

Exercices

# A : echo | openssl s_client -connect portail.helianthe.fr:443 -brief
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

# B : echo | openssl s_client -connect extranet.helianthe.fr:443 -brief
Protocol version: TLSv1.3
Peer Temp Key: X25519, 253 bits

# C : ssh -v admin@srv-sauvegarde
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com

# D : ssh admin@vieux-nas
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.