Les normes de cryptographie post-quantique du NIST sont finalisées — votre chrono de migration tourne

Le NIST a finalisé trois normes de cryptographie post-quantique en août 2024 : ML-KEM (FIPS 203, basé sur CRYSTALS-Kyber), ML-DSA (FIPS 204, basé sur CRYSTALS-Dilithium) et SLH-DSA (FIPS 205, basé sur SPHINCS+). Après une décennie d'évaluation et de multiples tours algorithmiques, celles-ci sont prêtes pour la production. Le chrono de migration a démarré le jour de la publication des normes — pas le jour où les ordinateurs quantiques arriveront.

Le calendrier pratique n'est pas abstrait. Le gouvernement américain a imposé aux agences fédérales de commencer la migration vers le PQC d'ici 2030 pour la plupart des systèmes, l'infrastructure classifiée devant migrer plus tôt. L'industrie est déjà en avance : Google Chrome a expédié du ML-KEM hybride dans TLS en 2023 et a depuis mis à jour vers la version finale FIPS 203. Apple a ajouté le PQC à iMessage avec iOS 17.4. Signal a mis à jour son protocole en 2024. Si vous exploitez une infrastructure devant rester sécurisée pendant 10 ans ou plus — en particulier tout ce qui implique un échange de clés asymétriques — la migration n'est pas optionnelle.

Harvest-Now-Decrypt-Later est une menace active

La raison pour laquelle l'urgence compte maintenant, même si des ordinateurs quantiques cryptographiquement pertinents n'existent pas encore, c'est l'attaque de type « récolter maintenant, déchiffrer plus tard » (HNDL). Des adversaires étatiques capturent le trafic chiffré aujourd'hui avec l'intention de le déchiffrer une fois la capacité quantique disponible. Les estimations du NIST, de la NSA et de la CISA placent les ordinateurs quantiques cryptographiquement pertinents (CRQC) dans 10 à 15 ans — exactement la fenêtre où les données capturées en 2026 pourraient être déchiffrées alors qu'elles ont encore une valeur de renseignement.

Si votre application touche à des données qui doivent rester confidentielles pendant une décennie — dossiers financiers, dossiers médicaux, communications, propriété intellectuelle, contrats gouvernementaux — l'adversaire n'a pas besoin d'un ordinateur quantique aujourd'hui. Il en a besoin tant que vous tenez encore à ce que ces données restent secrètes. La capture a lieu maintenant.

Triage : quoi migrer et quand

Tout ne doit pas bouger simultanément. L'ordre de triage correct est : échange de clés d'abord, signatures ensuite, chiffrement symétrique en dernier (ou jamais).

1. Échange de clés — priorité la plus élevée

L'échange de clés RSA et ECDH est ce que les ordinateurs quantiques cassent en premier. Remplacez-les par ML-KEM (Kyber). La rampe d'accès sécurisée standard est le mode hybride : exécuter simultanément classique et PQC. Si ML-KEM présente une faiblesse non découverte, l'algorithme classique vous protège toujours. Si un CRQC apparaît, la couche PQC vous couvre.

X25519MLKEM768 est l'hybride spécifique utilisé par Chrome, Cloudflare et AWS en production TLS aujourd'hui. Votre stack web le supporte peut-être déjà : OpenSSL 3.5 (sorti en avril 2025) inclut le support complet de ML-KEM et ML-DSA. L'activer est généralement un changement de configuration, pas de code.

2. Signatures numériques — priorité moyenne

ML-DSA (Dilithium) remplace RSA-PSS et ECDSA pour la signature. L'urgence ici est moindre car les signatures n'ont pas le problème HNDL — une signature n'a besoin d'être valide qu'au moment de la vérification, pas dans une décennie. Mettez les certificats de signature de code, les signatures de documents longue durée et les hiérarchies de CA internes sur votre feuille de route 2027–2028, pas sur votre sprint 2026.

3. Chiffrement symétrique — priorité faible

AES-256 et SHA-256 ne sont pas cassés par les ordinateurs quantiques. L'algorithme de Grover réduit de moitié leur longueur de clé effective, c'est pourquoi AES-256 est la recommandation standard depuis des années. Si vous utilisez déjà des clés symétriques 256 bits, le chiffrement symétrique ne nécessite aucune migration. Si vous êtes encore sur AES-128 pour des raisons de performance, passez à AES-256 — c'est l'étendue du travail ici.

Disponibilité des bibliothèques à mi-2026

L'écosystème a convergé vers les normes FIPS finalisées dans tous les langages majeurs :

Go

Le paquet standard crypto/tls supporte X25519MLKEM768 à partir de Go 1.24. Pour les opérations ML-KEM directes hors TLS, golang.org/x/crypto inclut un support stable pour ML-KEM 768 et 1024. L'API reflète les motifs de clés asymétriques existants : GenerateKey, Encapsulate, Decapsulate avec des tranches d'octets typées.

Python

pyca/cryptography 44.0.0 (novembre 2024) a ajouté ML-KEM via son backend OpenSSL 3.5. L'interface suit le même motif generate_private_key / exchange que les opérations EC existantes. Pour les environnements où vous ne pouvez pas contrôler la version d'OpenSSL, pqcrypto fournit une liaison directe aux implémentations C de référence.

Rust

La crate ml-kem du projet RustCrypto est une implémentation pure Rust, compatible no_std et entièrement conforme à FIPS 203. Elle supporte les variantes ML-KEM-512, 768 et 1024 et est le bon choix pour les cibles embarquées ou WASM où vous ne pouvez pas lier OpenSSL. Pour faire le pont avec des déploiements Kyber pré-norme, pqcrypto-kyber reste disponible.

Java / JVM

BouncyCastle 1.77+ supporte ML-KEM et ML-DSA avec une API stable. OpenJDK 24 a introduit ML-KEM en tant qu'API d'aperçu sous JEP 496, avec GA prévu pour JDK 25. Pour les déploiements de production JVM aujourd'hui, BouncyCastle est la voie fiable.

Activer le PQC hybride dans votre Service Mesh

Pour le mTLS interne entre services, le PQC hybride est réalisable sans modifications du code applicatif. Envoy Proxy 1.32+ supporte l'hybride X25519+ML-KEM lorsqu'il est compilé contre OpenSSL 3.5. Le changement est une mise à jour de configuration du service mesh dans votre liste de suites de chiffrement TLSParameters. Istio et Linkerd ont tous deux des chemins de migration documentés pour cette configuration.

Pour le TLS périphérique, Cloudflare et AWS CloudFront négocient déjà X25519MLKEM768 lorsque le client le supporte. Si vous terminez le TLS sur un CDN ou un équilibreur de charge que vous ne contrôlez pas, vérifiez le changelog de votre fournisseur — vous pourriez déjà avoir une couverture partielle du PQC sans le savoir.

Un calendrier concret sur trois ans

2026 : Auditez tous les échanges de clés sur les services exposés. Identifiez les versions d'OpenSSL sur l'ensemble du parc. Activez X25519MLKEM768 sur les endpoints HTTPS (changement de configuration). Documentez toute utilisation de RSA et ECDH dans des contextes non TLS : clés SSH, JWTs, PKI interne, toute dérivation de clé personnalisée.

2027 : Migrez les échanges de clés non TLS vers ML-KEM. Commencez la refonte de la hiérarchie de CA interne. Passez la signature de code à ML-DSA pour les nouvelles versions d'artefacts. Évaluez la migration des clés SSH (OpenSSH 9.x supporte le KEX hybride basé sur ML-KEM).

2028–2030 : Terminez la migration des signatures. Retirez RSA de toute nouvelle infrastructure. Atteignez la conformité avec NIST SP 800-131C et les exigences réglementaires applicables (directives HIPAA, dispositions PQC de PCI-DSS 5.0, normes techniques de la loi sur la cyber-résilience de l'UE).

Points à retenir pratiques

• Activez X25519MLKEM768 dans TLS 1.3 sur les endpoints publics dès aujourd'hui — c'est un changement de configuration avec un impact sur les performances négligeable sur le matériel moderne, et cela protège immédiatement contre le HNDL.
• Passez à OpenSSL 3.5+ ou BouncyCastle 1.77+ avant d'écrire tout nouveau code cryptographique ; ceux-ci incluent les implémentations finalisées de FIPS 203, 204 et 205.
• Auditez votre surface RSA et ECDH sur TLS, SSH, signature JWT, PKI interne et tout échange de clés personnalisé — l'échange de clés est la priorité la plus élevée, les signatures sont moyennes, le symétrique est en dernier.
• Utilisez le mode hybride (classique + PQC simultanément) comme chemin de migration, pas une transition brutale vers du PQC pur ; cela correspond à ce que Google, Cloudflare, AWS et Apple ont déployé.
• Si vous manipulez des données avec une exigence de confidentialité de 10 ans ou plus, traitez le HNDL comme une menace active actuelle et mettez la migration de l'échange de clés PQC sur votre feuille de route d'ingénierie 2026, pas 2028.