Préparer la migration post-quantique

Préparer la migration post-quantique

L’ordinateur quantique capable de casser la cryptographie à clé publique actuelle n’existe pas, et personne ne sait dire quand il existera. Cette incertitude n’autorise pourtant pas l’attente : les données chiffrées aujourd’hui peuvent être stockées et lues plus tard, et une migration cryptographique se compte en années. La PQC (Post-Quantum Cryptography, cryptographie post-quantique) désigne des algorithmes classiques, exécutés sur des ordinateurs ordinaires, conçus pour résister aussi à un attaquant quantique. Ce chapitre explique ce que change réellement le quantique, présente les familles d’algorithmes et les standards publiés, puis organise une migration progressive.

Explication de la marmotte

Cette page ressemble au plan d’un gardien d’immeuble qui décide de changer les serrures avant l’arrivée annoncée d’un passe-partout d’un genre nouveau, pas encore fabriqué. Personne ne sait quand il sera prêt, mais les coffres fermés aujourd’hui devront encore résister ce jour-là : mieux vaut donc recenser les portes et essayer les nouvelles serrures sans attendre.

→ Lire l’explication complète de la marmotte

Ce que change le quantique

Un ordinateur quantique manipule des qubits, qui peuvent se trouver dans une superposition d’états et s’intriquer entre eux. Il ne calcule pas « tout en parallèle », contrairement à la légende : il accélère certains problèmes dotés d’une structure exploitable, et pas les autres. La difficulté pratique est considérable. Les qubits physiques sont bruités, il faut des codes correcteurs d’erreurs pour en tirer des qubits logiques fiables, et les estimations publiées pour factoriser une clé RSA de 2048 bits se comptent encore en centaines de milliers à millions de qubits physiques, bien au-delà des machines existantes. On parle de CRQC (Cryptographically Relevant Quantum Computer) pour désigner la machine qui franchirait ce seuil.

Deux algorithmes résument la menace. L’algorithme de Shor (1994) résout en temps polynomial la factorisation et le logarithme discret, y compris sur les courbes elliptiques. Il casse donc RSA, Diffie-Hellman, ECDH, ECDSA et EdDSA, c’est-à-dire tout l’échange de clés et toutes les signatures déployés aujourd’hui. Augmenter la taille des clés n’y change rien : la menace est structurelle. L’algorithme de Grover (1996) accélère la recherche exhaustive, en ramenant environ 2^n essais à 2^(n/2) itérations. Pour le chiffrement symétrique et le hachage, l’effet est bien moindre qu’il n’y paraît, car ces itérations sont séquentielles et se parallélisent mal. AES-128 reste généralement considéré comme sûr, et AES-256 offre une marge confortable. La cryptographie symétrique ne demande donc pas de migration, tout au plus un passage à des clés de 256 bits pour les données les plus sensibles.

Le vrai sujet est celui des données de longue durée. La stratégie dite « collecter maintenant, déchiffrer plus tard » (harvest now, decrypt later) consiste à enregistrer aujourd’hui des échanges chiffrés pour les ouvrir quand un CRQC existera. L’inégalité de Mosca formalise le calcul : si x est la durée pendant laquelle une donnée doit rester confidentielle, y la durée de migration et z le délai avant l’apparition d’un CRQC, il y a un problème dès que x + y > z. Un secret industriel confidentiel pendant 30 ans, protégé par un système dont la migration prendra 5 ans, est exposé si un CRQC apparaît dans moins de 35 ans. Les signatures sont moins urgentes : une signature n’a besoin de résister que tant qu’elle est vérifiée, sauf pour les objets qui vivent longtemps, comme les certificats racines, les micrologiciels signés ou les archives probantes.

Familles post-quantiques

Les algorithmes post-quantiques reposent sur des problèmes pour lesquels aucun algorithme quantique efficace n’est connu.

La famille des treillis (lattices) s’appuie sur des problèmes comme LWE (Learning With Errors) et ses variantes structurées sur des modules. Elle offre le meilleur compromis entre taille et vitesse et fournit à la fois un mécanisme d’encapsulation de clé et des signatures. Les codes correcteurs d’erreurs reprennent l’idée de McEliece (1978) : décoder un code linéaire aléatoire est difficile. Classic McEliece a résisté à près d’un demi-siècle de cryptanalyse, mais ses clés publiques pèsent de quelques centaines de kilo-octets à plus d’un mégaoctet. Les signatures à base de hachage ne reposent que sur la sécurité d’une fonction de hachage, l’hypothèse la plus conservatrice qui soit ; leurs signatures sont volumineuses et lentes à produire. Les variantes avec état, XMSS et LMS, sont plus compactes mais imposent de ne jamais réutiliser un index, ce qui exige une gestion d’état irréprochable. Les schémas multivariés reposent sur la résolution de systèmes d’équations quadratiques ; Rainbow, finaliste du processus du NIST, a été cassé en 2022 par une attaque qui tournait en un week-end sur un ordinateur portable. Les isogénies de courbes elliptiques promettaient des clés très compactes ; SIKE, candidat au quatrième tour du NIST, a été cassé en 2022 en quelques heures par une attaque de Castryck et Decru. Ces deux épisodes valent leçon : un algorithme jeune peut s’effondrer d’un coup, ce qui justifie l’hybridation.

Le tableau suivant donne quelques ordres de grandeur, en octets, pour situer le coût des tailles et performances :

Algorithme	Usage	Clé publique	Chiffré ou signature
X25519	Échange de clés	32	32
ML-KEM-768	Encapsulation	1 184	1 088
Ed25519	Signature	32	64
RSA-2048	Signature	256 (module)	256
ML-DSA-65	Signature	1 952	3 309
SLH-DSA-128s	Signature	32	7 856

En vitesse, ML-KEM est comparable voire plus rapide qu’ECDH. Le coût est surtout dans la taille : un certificat ML-DSA et sa chaîne ajoutent plusieurs kilo-octets à chaque poignée de main, ce qui peut dépasser la taille d’un paquet et réveiller des équipements réseau qui supposaient des messages courts.

Standards et candidats

Le NIST (National Institute of Standards and Technology) a publié le 13 août 2024 trois normes FIPS (Federal Information Processing Standards). FIPS 203 définit ML-KEM, issu de CRYSTALS-Kyber, un KEM (Key Encapsulation Mechanism, mécanisme d’encapsulation de clé) à base de treillis, avec trois jeux de paramètres : ML-KEM-512, 768 et 1024. FIPS 204 définit ML-DSA, issu de CRYSTALS-Dilithium, signature à base de treillis en trois niveaux (44, 65, 87). FIPS 205 définit SLH-DSA, issu de SPHINCS+, signature à base de hachage sans état, présentée comme solution de repli reposant sur des hypothèses différentes.

En mars 2025, le NIST a sélectionné HQC, un KEM à base de codes, pour une normalisation future : il servira de mécanisme de secours si une faiblesse touchait les treillis. Falcon, autre signature à base de treillis aux signatures plus compactes mais à l’implémentation délicate (arithmétique à virgule flottante, risques de canaux auxiliaires), doit devenir FN-DSA dans une norme distincte, à suivre.

Il faut distinguer trois statuts. Un standard publié (FIPS 203, 204, 205) est figé et utilisable. Un candidat retenu (HQC) n’a pas encore de spécification finale. Un profil protocolaire décrit comment intégrer un algorithme dans TLS, X.509, SSH ou CMS : beaucoup de ces profils sont encore des brouillons de l’IETF (Internet Engineering Task Force), dont les identifiants peuvent changer avant publication. Le choix des paramètres suit les niveaux de sécurité du NIST : ML-KEM-768 vise le niveau 3, à peu près équivalent à AES-192, et constitue le choix par défaut le plus répandu. Le statut exact de chaque profil doit être vérifié au moment du déploiement, car il évolue de mois en mois.

Migrer sans rupture

Tout commence par l’inventaire : où la cryptographie à clé publique est-elle utilisée, avec quels algorithmes, quelles bibliothèques, quelles durées de vie de données ? On y trouve les flux TLS, les tunnels VPN, SSH, les certificats internes et externes, les signatures de code, les jetons, les sauvegardes chiffrées, les cartes à puce et les équipements embarqués. La méthode est détaillée dans la page sur la gouvernance et l’inventaire cryptographiques.

Vient ensuite l’hybride. Un échange de clés hybride combine un algorithme classique et un algorithme post-quantique, puis dérive la clé de session des deux secrets. La session reste sûre tant que l’un des deux tient : si ML-KEM révélait une faiblesse imprévue, X25519 protégerait encore ; si un CRQC apparaît, ML-KEM prend le relais. Le schéma d’une poignée de main TLS (Transport Layer Security) 1.3 hybride est le suivant : le client envoie dans son message ClientHello une part de clé X25519MLKEM768, qui concatène une clé publique ML-KEM-768 et une clé publique X25519 ; le serveur répond avec un chiffré ML-KEM et sa propre part X25519 ; les deux secrets partagés sont concaténés et passés dans la fonction de dérivation de TLS 1.3. Ce groupe est déjà activé par défaut dans les principaux navigateurs et dans OpenSSL depuis la version 3.5. Côté SSH, OpenSSH propose depuis la version 9.9 l’échange mlkem768x25519-sha256, devenu le choix par défaut en version 10.0. La protection contre la collecte anticipée progresse donc sans que la plupart des administrateurs aient rien fait, ce qui n’est pas une raison pour ne rien faire du reste.

L’interopérabilité est le principal risque technique : un ClientHello qui grossit d’environ un kilo-octet peut être fragmenté, et des pare-feu ou répartiteurs de charge mal écrits le rejettent. Les certificats sont le chantier le plus lent, car ils dépendent des autorités de certification, des navigateurs et du matériel qui les vérifie ; une chaîne entièrement ML-DSA reste rare. Les KMS (Key Management System, système de gestion de clés) et les HSM doivent supporter les nouveaux algorithmes et formats de clés, ce qui suppose souvent une mise à jour de micrologiciel. Enfin, chaque étape exige un plan de retour arrière (rollback) : pouvoir désactiver un groupe hybride ou revenir à une chaîne classique sans redéployer le parc, sous peine de transformer un incident de compatibilité en panne générale.

Exemples et ateliers

Classer les systèmes selon la collecte anticipée. Un tableau à trois colonnes suffit : durée de confidentialité requise, exposition du flux à une interception (Internet, liaison louée, réseau interne), et date de migration possible. Un portail public de prise de rendez-vous, aux données périssables, arrive en bas de liste. Un tunnel entre deux sites qui transporte des dossiers de ressources humaines, conservés des décennies, arrive en tête, même si son trafic paraît anodin aujourd’hui.

Préparer un inventaire PQC. Pour chaque système, on note l’algorithme d’échange de clés, l’algorithme de signature, la bibliothèque et sa version, le propriétaire, la durée de vie des données et la possibilité de mettre à jour. Une commande comme openssl s_client -connect exemple.fr:443 -groups X25519MLKEM768 permet de tester si un serveur accepte le groupe hybride, et ssh -Q kex liste les échanges de clés supportés par un client OpenSSH.

Comparer KEM et signatures. Le tableau précédent montre que l’impact porte surtout sur les signatures : un échange ML-KEM ajoute environ 2,2 kilo-octets à la poignée de main, alors qu’une chaîne de deux certificats ML-DSA-65 avec une signature de poignée de main en ajoute près de 14. C’est pourquoi l’échange de clés migre en premier, et les signatures ensuite.

Pièges classiques

Attendre l’annonce d’un CRQC pour commencer l’inventaire, c’est s’assurer d’avoir plusieurs années de retard le jour où il deviendra urgent, et de laisser exposées toutes les données captées entre-temps. Remplacer tous les algorithmes d’un coup sans phase hybride ni test de compatibilité expose à des pannes difficiles à diagnostiquer et prive de la protection contre une faiblesse des nouveaux algorithmes. Migrer les bibliothèques en oubliant les protocoles et les certificats laisse les flux réels inchangés. Enfin, présenter la migration comme une garantie de sécurité absolue relève de la promesse électorale : les algorithmes post-quantiques sont plus jeunes que RSA, leurs implémentations le sont encore plus, et les erreurs d’implémentation ne disparaissent pas par changement de mathématiques.

À ne pas confondre

Cryptographie quantique et post-quantique : la première, dont la QKD (Quantum Key Distribution, distribution quantique de clés) est l’exemple le plus connu, utilise des phénomènes physiques et du matériel dédié ; la seconde est du logiciel classique. KEM et signature : le KEM protège la confidentialité de l’échange de clés et doit migrer tôt à cause de la collecte anticipée ; la signature protège l’authenticité au moment de la vérification. Migration algorithmique et migration de protocole : disposer de ML-KEM dans une bibliothèque ne sert à rien tant que le protocole ne sait pas le négocier. Sécurité post-quantique et sécurité post-compromission : la seconde (post-compromise security) désigne la capacité d’un protocole à retrouver la confidentialité après la fuite d’une clé, comme le fait le cliquet de Signal ; elle n’a aucun rapport avec les ordinateurs quantiques. La démarche générale de changement d’algorithmes est reprise dans la page sur le choix, la combinaison et la migration.

🐝 Ce qui arrive si on s’en passe

Sans inventaire ni préparation, la migration ne se conduit plus au rythme choisi. Les échanges chiffrés captés aujourd’hui restent stockés chez qui les a interceptés, et aucune mise à jour future ne les protège rétroactivement : les secrets à longue durée de vie ont déjà une date de lecture probable, fixée par les progrès du matériel quantique et non par l’organisation. S’y ajoute une dette de compatibilité : des équipements incapables de traiter des clés et des signatures plus volumineuses se découvrent en production, précisément là où un essai préalable les aurait signalés sans casse.

🦫 Explication de la marmotte 🍫

Un ordinateur quantique calcule d’une manière différente des ordinateurs actuels. S’il devient assez puissant, il pourra exécuter l’algorithme de Shor, qui casse les méthodes de chiffrement à clé publique employées aujourd’hui, car elles reposent sur la difficulté de décomposer de grands nombres en facteurs ou de calculer des logarithmes discrets. L’algorithme de Grover, lui, accélère seulement l’essai de toutes les clés possibles : pour le chiffrement à clé secrète partagée, des clés plus longues suffisent. Construire une telle machine reste très difficile, mais un attaquant peut enregistrer dès maintenant des échanges chiffrés pour les déchiffrer plus tard. Les données qui doivent rester secrètes longtemps sont donc exposées dès aujourd’hui. La réponse consiste à adopter de nouveaux algorithmes, fondés sur d’autres problèmes mathématiques jugés difficiles même pour un ordinateur quantique : les treillis, qui sont des grilles de points dans un espace à très nombreuses dimensions, les codes correcteurs d’erreurs ou les fonctions de hachage. Des standards officiels sont déjà publiés pour établir une clé et pour signer. La migration commence par l’inventaire de tous les endroits où la cryptographie est utilisée. Vient ensuite un mode hybride, qui combine l’ancien et le nouvel algorithme pour rester protégé si l’un des deux cède. Il faut enfin tester la compatibilité, adapter certificats et protocoles, et prévoir un retour arrière.

À lire aussi

• Intégrer la cryptographie post-quantique dans TLSMigration progressive de TLS vers les mécanismes post-quantiques hybrides, face à la menace store now, decrypt later.
• Les problèmes difficiles qui rendent la clé publique possiblePrésenter les objets mathématiques nécessaires sans transformer le site en manuel abstrait, et relier chaque difficulté à une famille de primitives.
• Dimensionner un HSM pour la migration post-quantiqueImpact des algorithmes post-quantiques sur la capacité, les performances et l'exploitation des modules cryptographiques matériels existants.
• Courbes elliptiques : compacité, validation et piègesRendre les courbes elliptiques utilisables sans excès d’algèbre, en insistant sur le choix de courbe, les encodages et les erreurs de validation.

Pages voisines

La citent

• Comprendre la cryptanalyse sans perdre le fil pratique
• Courbes elliptiques : compacité, validation et pièges
• Évaluer la force d’une protection
• Les problèmes difficiles qui rendent la clé publique possible
• RSA : trappe, padding et usages restreints
• NSA Cybersecurity

Préparer la migration post-quantique

Elle cite

• ⇄Lien dans les deux sens :Gouverner la cryptographie: inventaire, agilité et conformité
• ⇄Lien dans les deux sens :Informatique quantique : histoire, acteurs, usages et avenir
• ⇄Lien dans les deux sens :Le post-quantique hybride
• ⇄Lien dans les deux sens :Récolter maintenant, déchiffrer plus tard
• Choisir, combiner et migrer les algorithmes symétriques

⇄ : les deux pages se citent l’une l’autre.