En août 2024, le NIST a officiellement standardisé trois algorithmes cryptographiques résistants aux ordinateurs quantiques : ML-KEM (FIPS 203), ML-DSA (FIPS 204) et SLH-DSA (FIPS 205). En avril 2025, OpenSSL 3.5 est la première version de la bibliothèque la plus déployée au monde à les intégrer en stable. C'est le début d'une migration qui va s'étaler sur des années, mais qu'il faut comprendre maintenant.
Pourquoi la cryptographie actuelle va devenir un problème
RSA et les courbes elliptiques (ECDSA, ECDH) reposent sur des problèmes mathématiques que les ordinateurs classiques mettent des milliards d'années à résoudre. Un ordinateur quantique suffisamment puissant pourrait les casser en quelques heures grâce à l'algorithme de Shor.
Aucun ordinateur quantique n'est encore capable de casser du RSA-2048 en 2025. Mais l'attaque dite du harvest now, decrypt later est déjà en cours : des acteurs malveillants collectent aujourd'hui des données chiffrées, en attendant d'avoir la puissance de calcul pour les déchiffrer dans 5 à 15 ans. Tout ce qui doit rester confidentiel sur le long terme est potentiellement exposé.
Les trois algorithmes standardisés par le NIST
ML-KEM (Module-Lattice Key Encapsulation Mechanism) remplace ECDH pour l'échange de clés. C'est l'algorithme qu'on utilisera pour établir des sessions TLS sécurisées contre les attaques quantiques. Il est basé sur les problèmes de réseaux euclidiens, réputés résistants aux algorithmes quantiques connus.
ML-DSA (Module-Lattice Digital Signature Algorithm) remplace ECDSA pour les signatures numériques. Il sert à authentifier les certificats, les mises à jour logicielles, les tokens JWT.
SLH-DSA (Stateless Hash-based Digital Signature Algorithm) est une alternative conservative basée sur les fonctions de hachage, dont la sécurité est mieux comprise et dépend de moins d'hypothèses mathématiques.
Ce qu'OpenSSL 3.5 apporte concrètement
OpenSSL 3.5 permet d'utiliser ces algorithmes via son API standard. On peut créer des certificats ML-DSA, établir des sessions TLS avec ML-KEM, et signer des données avec SLH-DSA. La bibliothèque supporte également le mode hybride : combiner un algorithme classique (ECDH) et un algorithme post-quantique (ML-KEM) dans la même session. C'est la stratégie recommandée pour la transition : si l'algorithme post-quantique est compromis d'une façon encore inconnue, l'algorithme classique prend le relais.
Node.js, Python, Ruby, Go et la plupart des runtimes modernes utilisent OpenSSL sous le capot. La disponibilité dans ces écosystèmes suivra progressivement les mises à jour des distributions.
Ce que les développeurs doivent faire maintenant
La migration ne se fait pas du jour au lendemain, mais voici les actions concrètes à prendre dans les mois qui viennent.
- Identifier quelles données de votre application doivent rester confidentielles sur 10 ans ou plus (données médicales, financières, identitaires). Ce sont les premières à migrer.
- Mettre à jour OpenSSL vers la branche 3.x si ce n'est pas encore fait : la branche 1.1.x n'aura pas les algorithmes post-quantiques.
- Suivre le support TLS hybride dans votre stack. Cloudflare, Google et AWS l'expérimentent déjà sur leurs infrastructures.
- Éviter de déployer de nouveaux systèmes qui reposent sur RSA-2048 pour des usages à longue durée de vie.
Une migration sur une décennie, pas sur un sprint
La transition de la cryptographie classique vers la cryptographie post-quantique est comparable à la migration de HTTP vers HTTPS : une décennie de déploiement progressif, avec une période de coexistence des deux approches. La différence, c'est que cette fois le signal d'alarme est connu à l'avance, ce qui permet de s'y préparer sans urgence aujourd'hui, mais sans procrastiner non plus.
- FIPS 203 : ML-KEM Standard — NIST, août 2024
- OpenSSL Blog : version 3.5 — OpenSSL Project, avril 2025
- The state of post-quantum cryptography — Cloudflare, 2024
