Les normes post-quantiques du NIST sont arrivées. Votre infrastructure n'est pas prête.
En août 2024, le National Institute of Standards and Technology (NIST) a publié trois normes finalisées de cryptographie post-quantique (PQC) : FIPS 203 (ML-KEM, basé sur CRYSTALS-Kyber), FIPS 204 (ML-DSA, basé sur CRYSTALS-Dilithium) et FIPS 205 (SLH-DSA, basé sur SPHINCS+). Elles représentent l'aboutissement d'un processus de normalisation de huit ans commencé en 2016. Les normes existent. Le modèle de menace est réel. Ce qui n'a pas encore eu lieu, c'est une migration significative de l'infrastructure réelle d'Internet.
Les algorithmes cryptographiques qui protègent la majeure partie d'Internet aujourd'hui — RSA-2048, ECDH P-256, ECDSA — reposent sur des problèmes mathématiques (factorisation d'entiers et logarithme discret) que les ordinateurs classiques ne peuvent pas résoudre efficacement. Un ordinateur quantique cryptographiquement pertinent (CRQC) exécutant l'algorithme de Shor pourrait les briser en quelques heures. Une telle machine n'existe pas aujourd'hui, mais la menace « récolter maintenant, déchiffrer plus tard » est déjà active : des acteurs étatiques collectent aujourd'hui du trafic chiffré dans l'intention de le déchiffrer une fois que le matériel quantique aura mûri.
Ce que le NIST a réellement normalisé
FIPS 203 / ML-KEM est le mécanisme principal d'encapsulation de clés pour le chiffrement général et l'échange de clés — le remplacement direct de RSA et ECDH dans des protocoles comme TLS. Il propose trois jeux de paramètres : ML-KEM-512, ML-KEM-768 et ML-KEM-1024, équilibrant le niveau de sécurité avec les tailles de clés et de textes chiffrés. ML-KEM-768 est considéré comme le choix par défaut pratique, offrant une sécurité comparable à AES-192.
FIPS 204 / ML-DSA gère les signatures numériques, remplaçant RSA et ECDSA dans les chaînes de certificats, la signature de code et les systèmes d'authentification. Comme ML-KEM, il se décline en trois variantes de paramètres (ML-DSA-44, ML-DSA-65, ML-DSA-87). L'inconvénient : les signatures ML-DSA sont nettement plus grandes que les signatures ECDSA — ML-DSA-65 produit des signatures de 3 309 octets contre 64–72 octets pour ECDSA. Cela a des implications réelles sur la taille des chaînes de certificats dans les négociations TLS.
FIPS 205 / SLH-DSA est un schéma de signature basé sur le hachage sans état, plus conservateur dans ses hypothèses de sécurité que ML-DSA car il repose uniquement sur la sécurité de la fonction de hachage plutôt que sur des problèmes de réseaux. Il est plus lent et produit des signatures plus grandes, ce qui le rend mieux adapté aux signatures de longue durée sur les certificats racines et les firmware qu'à l'authentification à haut débit.
Où en est vraiment Internet aujourd'hui
La prise en charge par les navigateurs de l'échange de clés hybride est arrivée avant que les normes ne soient finalisées. Chrome a activé X25519Kyber768 (un hybride combinant ECDH classique avec Kyber) par défaut dans Chrome 124 (avril 2024). Cloudflare et Google utilisent du PQC hybride pour TLS depuis fin 2023 sur leur infrastructure périphérique. Mais cela ne couvre que l'échange de clés — les chaînes de certificats validant l'identité du serveur utilisent encore ECDSA ou RSA partout.
L'écosystème des certificats est essentiellement non migré. Les quelque 200 millions de certificats TLS actifs utilisés à mi-2025 sont en grande majorité ECDSA ou RSA. Les autorités de certification, dont DigiCert et Let's Encrypt, ont commencé à tester la délivrance de certificats PQC mais n'ont pas encore déployé de certificats PQC de production à grande échelle. Le problème s'aggrave : les certificats PQC avec signatures ML-DSA augmenteraient considérablement la taille des négociations TLS, risquant de casser les clients ayant des limites strictes de taille de paquet ou d'affecter les performances sur les connexions à haute latence.
Les protocoles VPN sont également à la traîne. Les implémentations de WireGuard, OpenVPN et IPsec/IKEv2 varient considérablement en matière de support PQC. OpenSSH a ajouté la prise en charge de l'échange de clés hybride sntrup761x25519-sha512 dans la version 8.5 (2021) et l'a rendu par défaut dans la 9.0 (2022), ce qui en fait l'une des premières intégrations PQC largement déployées. Mais les produits VPN utilisés dans les environnements d'entreprise — Cisco, Palo Alto, Fortinet — ont des calendriers variables, beaucoup planifiant encore le support PQC pour 2026–2027.
Le calendrier auquel les organisations sont confrontées
Le calendrier du gouvernement américain est le plus prescriptif. La suite d'algorithmes de sécurité nationale commerciale 2.0 (CNSA 2.0) de la NSA impose la migration vers la PQC pour les systèmes de sécurité nationale, avec des échéances différentes selon le type de système. Signature des logiciels et firmware : d'ici 2025. Équipements réseau : d'ici 2026. Systèmes d'exploitation : d'ici 2027. La plupart des systèmes gouvernementaux classifiés et sensibles : d'ici 2033. Les propres directives du NIST dans la publication spéciale 1800-38B fournissent une feuille de route de migration pour les agences fédérales avec des calendriers similaires.
Pour les organisations privées, il n'y a pas encore de mandat réglementaire — mais cela change. La directive NIS2 de l'UE inclut des exigences d'agilité cryptographique, et l'ENISA (l'Agence de l'UE pour la cybersécurité) a publié des directives de migration PQC recommandant aux organisations de terminer les phases d'inventaire et de planification d'ici 2025 et de commencer la migration active d'ici 2026. Les régulateurs du secteur financier au Royaume-Uni et dans l'UE ont publié des directives similaires.
La fenêtre « récolter maintenant, déchiffrer plus tard » est le moteur critique de la priorisation. Toute donnée ayant une exigence de confidentialité au-delà de 5 à 10 ans doit être considérée comme déjà à risque si elle est transmise aujourd'hui avec une cryptographie classique. Les dossiers médicaux, les accords financiers, la propriété intellectuelle et les communications classifiées entrent tous dans cette catégorie.
Les défis techniques qu'implique réellement la migration
La migration vers la PQC n'est pas un simple remplacement. Les tailles plus grandes des clés et des signatures dans les algorithmes post-quantiques créent des problèmes de compatibilité en cascade. Les clés publiques ML-KEM-768 font 1 184 octets contre 32 octets pour X25519. Les clés publiques ML-DSA-65 font 1 952 octets. Les protocoles avec en-têtes de taille fixe, les modules de sécurité matériels avec limites de taille de clé et les firmware HSM antérieurs à la PQC nécessitent tous des mises à jour ou un remplacement.
Les bibliothèques cryptographiques sont en avance sur la plupart des applications. OpenSSL 3.x prend en charge la PQC via le fournisseur Open Quantum Safe (OQS). BoringSSL (utilisé par Chrome et Android) a intégré Kyber. La bibliothèque liboqs validée par le NIST fournit des implémentations de référence. Mais les intégrer dans des systèmes de production nécessite des tests de régression de performances, en particulier sur les systèmes embarqués et les appareils IoT contraints où la surcharge de calcul de ML-KEM peut être significative.
L'infrastructure des autorités de certification nécessite des mises à jour substantielles. La délivrance de certificats PQC nécessite la mise à jour du logiciel de l'AC, des HSM capables d'opérations ML-DSA, des répondeurs OCSP et des points de distribution CRL. L'ensemble de la chaîne PKI — AC racines, AC intermédiaires, certificats feuilles — doit migrer de manière coordonnée tout en maintenant la rétrocompatibilité pendant une période de transition qui pourrait s'étendre sur une décennie.
Ce que les organisations doivent faire maintenant
Réaliser un inventaire cryptographique. Cartographiez chaque système, service et flux de données utilisant la cryptographie à clé publique. Cela inclut les points de terminaison TLS, les VPN, l'infrastructure SSH, les pipelines de signature de code, les systèmes PKI, les bases de données chiffrées et tout HSM ou carte à puce. La publication spéciale 1800-38B du NIST fournit une méthodologie détaillée pour ce processus d'inventaire.
Prioriser selon la sensibilité et la longévité des données. Les systèmes qui transmettent ou stockent des données nécessitant une confidentialité au-delà de 2030 doivent être en tête de la file d'attente de migration. Les attaques de type récolter-maintenant-déchiffrer-plus tard rendent la menace réelle aujourd'hui même si l'ordinateur quantique n'existe pas encore.
Activer la cryptographie hybride là où elle est disponible. Les modes hybrides (classique + PQC) offrent une résistance quantique sans sacrifier la sécurité classique si l'algorithme PQC s'avère vulnérable. La RFC 9370 de l'IETF normalise l'échange de clés hybride pour TLS 1.3. La plupart des bibliothèques TLS modernes prennent en charge le mode hybride X25519MLKEM768 aujourd'hui.
Mettre à jour les dépendances des bibliothèques cryptographiques. Mettez à niveau vers OpenSSL 3.3+, les builds BoringSSL datant d'après janvier 2024, ou l'équivalent avec le support du fournisseur OQS. Auditez tout code cryptographique intégré ou accélération matérielle qui pourrait coder en dur des hypothèses d'algorithmes classiques.
Contactez votre autorité de certification et vos fournisseurs PKI. Interrogez DigiCert, Sectigo, Let's Encrypt et les opérateurs d'AC internes sur leurs feuilles de route de migration PQC et leurs engagements calendaires. Intégrez ces dates dans vos propres horizons de planification.
Planifiez des tests de performance. Les algorithmes PQC ne sont pas uniformément plus lents, mais ils sont différents. ML-KEM est rapide en logiciel ; les signatures basées sur le hachage comme SLH-DSA sont lentes. Évaluez vos charges de travail spécifiques, en particulier tout ce qui effectue de gros volumes de vérification de signatures, comme un CDN, un équilibreur de charge ou un service d'authentification à grande échelle.
La menace quantique n'est pas imminente au sens où « un CRQC existera l'année prochaine ». Des estimations crédibles d'IBM, Google et de chercheurs universitaires situent l'informatique quantique cryptographiquement pertinente à au moins 10 à 15 ans dans les trajectoires actuelles. Mais les migrations cryptographiques prennent de 5 à 15 ans pour être achevées sur des infrastructures complexes. Le NIST a publié les normes. L'horloge de la migration a commencé. Les organisations qui commencent une planification systématique et une migration précoce dès maintenant éviteront les situations de crise lorsque les délais réglementaires arriveront — ou lorsqu'une percée de l'informatique quantique déplacera le calendrier.