Les standards de cryptographie post-quantique du NIST sont définitifs — voici le calendrier de migration que chaque organisation doit connaître

Les standards sont définitifs. Le compte à rebours est lancé.

En août 2024, le National Institute of Standards and Technology (NIST) a publié FIPS 203, FIPS 204 et FIPS 205 — les premiers standards de cryptographie post-quantique (PQC) finalisés de l'histoire. Au terme de près d'une décennie d'évaluation, l'agence a standardisé trois algorithmes : ML-KEM (Module Lattice Key Encapsulation Mechanism, basé sur Kyber), ML-DSA (Module Lattice Digital Signature Algorithm, basé sur Dilithium) et SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, basé sur SPHINCS+). Un quatrième algorithme, FN-DSA (basé sur Falcon), devrait être standardisé dans une prochaine publication FIPS. Ce ne sont pas des propositions ni des brouillons. Ce sont des standards, et la directive du NIST est claire : commencez la migration maintenant.

L'urgence ne tient pas à ce que les ordinateurs quantiques sont capables de faire en 2026 — elle tient à ce qu'ils pourront faire entre 2030 et 2035, et à ce que font déjà certains adversaires aujourd'hui. Le modèle de menace harvest-now-decrypt-later implique que des acteurs étatiques et des attaquants bien financés capturent dès maintenant du trafic chiffré, le stockent, et parient qu'un ordinateur quantique cryptographiquement pertinent (CRQC) finira par le déchiffrer. Toute donnée devant rester confidentielle pendant plus de cinq à dix ans est déjà exposée — dossiers médicaux, contrats financiers, communications gouvernementales, propriété intellectuelle.

Ce que les ordinateurs quantiques peuvent réellement casser — et quand

Les ordinateurs quantiques d'aujourd'hui sont des machines bruyantes et de petite envergure. Le processeur Heron d'IBM et les systèmes similaires opèrent dans une plage de quelques centaines à quelques milliers de qubits physiques, loin des millions de qubits logiques corrigés des erreurs nécessaires pour exécuter l'algorithme de Shor contre RSA-2048 ou ECDSA P-256. Les machines actuelles ne peuvent casser aucun système cryptographique en production. L'estimation réaliste pour un CRQC capable de briser RSA-2048 se situe entre 2030 et 2035, certaines projections optimistes l'avançant si la correction d'erreurs progresse plus vite que prévu.

Ce que l'algorithme de Shor peut casser : RSA (toutes les tailles de clés en usage pratique), l'échange de clés Diffie-Hellman (y compris les variantes à corps fini et à courbe elliptique) et les signatures ECDSA/EdDSA. Ce qu'il ne casse pas : les chiffrements symétriques comme AES-256, qui nécessitent seulement un doublement de la taille de clé (l'algorithme de Grover n'apporte qu'une accélération quadratique). TLS 1.3, tel que déployé aujourd'hui, s'appuie sur ECDHE pour l'échange de clés et sur ECDSA ou RSA pour l'authentification des certificats — les deux sont vulnérables à long terme. SHA-256 et SHA-3 sont considérés comme résistants aux attaques quantiques aux tailles de sortie actuelles, avec une légère réduction de la marge de sécurité.

Les trois nouveaux algorithmes : détails techniques

ML-KEM (FIPS 203 / Kyber) est le standard principal pour l'encapsulation de clés — le mécanisme utilisé pour établir des secrets partagés dans des protocoles comme TLS. Il repose sur des problèmes de réseaux modulaires (plus précisément le problème Module Learning With Errors). Au jeu de paramètres ML-KEM-768 (environ 128 bits de sécurité quantique), les clés publiques font 1 184 octets et les chiffrés 1 088 octets — plus volumineux que la clé publique RSA-2048 de 256 octets, mais les performances sont remarquables : ML-KEM-768 atteint environ 15 000 à 20 000 encapsulations par seconde sur un cœur serveur moderne, contre environ 3 000 à 5 000 opérations RSA-2048 par seconde pour la génération de clés. La décapsulation est tout aussi rapide. La génération de clés dans ML-KEM est nettement plus rapide que dans RSA.

ML-DSA (FIPS 204 / Dilithium) est le standard principal pour les signatures numériques. À ML-DSA-65 (environ 128 bits de sécurité quantique), les signatures font 3 293 octets et les clés publiques 1 952 octets. Le débit de signature atteint environ 5 000 à 8 000 signatures par seconde par cœur, avec une vérification encore plus rapide. À titre de comparaison, ECDSA P-256 signe à environ 20 000 à 40 000 opérations par seconde — ML-DSA est plus lent, mais l'écart reste gérable pour la plupart des applications. La taille plus importante des signatures est le principal défi d'intégration, notamment pour les chaînes de certificats et les environnements contraints.

SLH-DSA (FIPS 205 / SPHINCS+) est un schéma de signature basé sur les fonctions de hachage, offrant une base de sécurité conservative et bien comprise. Il repose uniquement sur la sécurité de la fonction de hachage sous-jacente (SHA-256 ou SHAKE), et non sur des hypothèses de dureté des réseaux. La contrepartie se situe au niveau des performances et de la taille : SLH-DSA-128s produit des signatures de 7 856 octets et signe à environ 100 à 500 opérations par seconde selon le jeu de paramètres. Il convient mieux aux cas d'usage à haute assurance — signature de firmware, autorités de certification racines, ou tout contexte où la signature est peu fréquente et où la taille des signatures est acceptable.

Échange de clés hybride : le pont de transition sûr

Parce que les nouveaux algorithmes sont moins éprouvés que RSA et ECDH — qui bénéficient de décennies de cryptanalyse réelle — la voie de migration recommandée est l'échange de clés hybride : combiner un algorithme classique avec un algorithme post-quantique, de sorte que la sécurité tienne tant que l'un ou l'autre reste inviolé. La RFC 9180 de l'IETF (HPKE) et les projets de standards pour l'échange de clés hybride PQC dans TLS 1.3 définissent des mécanismes concrets. Google Chrome a déjà activé par défaut l'échange de clés hybride X25519+ML-KEM-768 à partir de Chrome 131 (fin 2024). Cloudflare, AWS et Azure déploient ou ont déjà déployé du PQC hybride dans leur infrastructure de terminaison TLS. La surcharge de performance liée à l'ajout de ML-KEM à une négociation TLS existante représente environ 1 à 2 millisecondes de latence supplémentaire et environ 2 Ko de données de négociation additionnelles — négligeable pour la plupart des applications.

Calendrier de migration selon la taille de l'organisation

Grandes entreprises et infrastructures critiques (2024–2027) : Commencez dès maintenant l'inventaire cryptographique. Identifiez tous les systèmes utilisant RSA, ECDSA, ECDH et Diffie-Hellman. Priorisez les secrets à longue durée de vie et les dépôts de données hautement sensibles. Déployez TLS hybride avec ML-KEM sur les services exposés à Internet. Mettez à jour les pipelines d'émission de certificats pour prendre en charge ML-DSA. Travaillez avec les fournisseurs sur les calendriers de support firmware et HSM. Le NIST recommande aux grandes organisations de finaliser la migration principale d'ici 2030.

Organisations de taille intermédiaire (2025–2028) : Tirez parti du support PQC des fournisseurs cloud (AWS Certificate Manager, Google Cloud et Azure ajoutent des options de certificats PQC). Activez le PQC hybride dans les load balancers et les API gateways dès que les options de configuration sont disponibles. Mettez à jour les solutions VPN et d'accès distant — de nombreux fournisseurs (Cisco, Palo Alto, Fortinet) ont annoncé ou livré un support PQC.

Petites organisations (2026–2030) : Suivez l'évolution de vos logiciels et fournisseurs cloud. Mettez à jour les bibliothèques TLS (OpenSSL 3.x, BoringSSL et liboqs prennent déjà en charge ML-KEM et ML-DSA). Migrez les autorités de certification lorsque votre CA supporte FIPS 203/204. L'essentiel du travail arrivera naturellement avec les mises à jour des outils standard.

Checklist de migration

• Inventaire : Cataloguez toutes les dépendances cryptographiques — certificats TLS, clés SSH, certificats de signature de code, configurations VPN, données chiffrées au repos et clés stockées dans des HSM.
• Prioriser selon la durée de vie des données : Tout secret devant rester confidentiel après 2030 nécessite dès aujourd'hui une protection contre les attaques harvest-now-decrypt-later.
• Activer TLS hybride : Déployez X25519+ML-KEM-768 sur tous les endpoints TLS 1.3. La plupart des grands fournisseurs CDN et load balancer le supportent déjà ou le feront dans les versions 2025.
• Mettre à jour les chaînes de certificats : Planifiez la migration vers les certificats ML-DSA. Suivez la feuille de route de votre CA et testez en staging avec liboqs ou des builds OpenSSL compatibles OQS.
• Auditer les pipelines de signature de code : Remplacez la signature basée sur ECDSA par ML-DSA ou SLH-DSA pour les firmware, les images de conteneurs et les paquets logiciels.
• Évaluer les HSM et la gestion des clés : Confirmez que votre fournisseur HSM supporte FIPS 203/204/205. Thales, Entrust et AWS CloudHSM ont publié des feuilles de route PQC.
• Mettre à jour SSH : OpenSSH 9.0+ supporte l'échange de clés hybride ML-KEM. Activez-le pour les infrastructures d'accès privilégié.
• Tester les performances dans votre environnement : Exécutez des benchmarks ML-KEM et ML-DSA avec liboqs avant de vous engager sur des choix de jeux de paramètres.
• Former votre équipe : Les ingénieurs en sécurité doivent comprendre à un niveau conceptuel les hypothèses de la cryptographie basée sur les réseaux pour évaluer les affirmations des fournisseurs et la qualité des implémentations.
• Fixer une date limite ferme : Le NIST recommande de déprécier RSA et ECC pour l'établissement de clés et les signatures d'ici 2030. Intégrez cette date dans votre feuille de route sécurité dès maintenant.

La transition post-quantique est la plus grande migration d'infrastructure cryptographique depuis le passage de SSL à TLS — avec une échéance encore plus contraignante. Les algorithmes sont finalisés, les implémentations arrivent à maturité, et les navigateurs ainsi que les fournisseurs cloud sont déjà en mouvement. La seule variable est de savoir si votre organisation migrera selon son propre calendrier ou se retrouvera à improviser lorsque la menace deviendra critique.