Le 13 août 2024, le NIST a publié trois normes qui changent la manière dont le web va signer ses certificats, ses mises à jour logicielles et ses transactions. Deux ans plus tard, en ce 10 septembre 2026, ces normes sortent des laboratoires et entrent dans les feuilles de route des RSSI. ML-DSA, SLH-DSA et un troisième candidat encore en projet, FN-DSA, se disputent la place de signature numérique de référence pour l’ère post-quantique. Le choix n’est pas cosmétique : selon l’algorithme retenu, une signature peut peser 666 octets ou 49 856 octets, un écart de près de 75 fois pour un niveau de sécurité comparable. Ce comparatif détaille les spécifications officielles, les benchmarks disponibles, les coûts de déploiement et les cas d’usage réels pour aider les équipes techniques françaises et européennes à choisir la bonne signature post-quantique avant les échéances réglementaires de 2027.
Pourquoi la cryptographie post-quantique presse maintenant
L’algorithme de Shor, s’il tourne un jour sur un ordinateur quantique suffisamment stable, casserait RSA et les courbes elliptiques en un temps polynomial. Personne ne sait quand cette machine existera, mais le risque n’attend pas cette date. Des données chiffrées aujourd’hui avec RSA-2048 peuvent être interceptées et stockées maintenant pour être déchiffrées plus tard, une stratégie que les experts appellent “harvest now, decrypt later”. Pour des données à durée de vie longue (dossiers médicaux, secrets industriels, archives d’État), la fenêtre de vulnérabilité s’est déjà ouverte.
Les estimations sur la date d’apparition d’un ordinateur quantique cryptographiquement pertinent varient fortement selon les chercheurs interrogés, allant de la prochaine décennie à un horizon plus lointain. Cette incertitude ne change rien à la logique de migration : un certificat signé aujourd’hui protège des données qui peuvent rester sensibles pendant dix, vingt ou cinquante ans selon le secteur. Attendre une date de certitude absolue avant d’agir revient à parier que la fenêtre de vulnérabilité ne s’ouvrira jamais, un pari que ni le NIST ni l’ANSSI ne recommandent de prendre.
Le NIST a répondu avec trois standards finalisés le même jour : FIPS 203 (ML-KEM, pour l’échange de clés), FIPS 204 (ML-DSA, pour la signature) et FIPS 205 (SLH-DSA, également une signature, mais bâtie sur un fondement mathématique différent). Un quatrième algorithme de signature, FN-DSA, dérivé de Falcon, a été sélectionné par le NIST mais reste au stade de projet sous la référence FIPS 206, avec un brouillon attendu fin 2026 et une finalisation probable en 2027. Cet article compare les trois candidats à la signature : ML-DSA, SLH-DSA et FN-DSA.
Ce n’est pas une décision improvisée. Le concours du NIST a démarré en 2016, avec un appel public à soumissions. Une soixantaine d’équipes de recherche ont participé aux premiers tours, avant que le NIST n’annonce en 2022 ses quatre premiers lauréats : CRYSTALS-Kyber pour l’échange de clés, et CRYSTALS-Dilithium, Falcon et SPHINCS+ pour la signature. Renommés et formalisés dans les publications FIPS, ces trois derniers sont devenus respectivement ML-DSA, FN-DSA et SLH-DSA. Huit ans de sélection publique, d’attaques cryptanalytiques et de révisions séparent l’appel à candidatures initial des normes que les équipes techniques évaluent aujourd’hui.
La difficulté supplémentaire, pour qui débarque sur ce sujet, tient au nom même des algorithmes. Un lecteur qui a suivi la cryptographie post-quantique en 2022 connaît sans doute Dilithium, Falcon et SPHINCS+, comme le détaille notre comparatif Kyber vs Dilithium publié à l’époque. Un lecteur qui découvre le sujet en 2026 rencontre ML-DSA, FN-DSA et SLH-DSA. Ce sont les mêmes algorithmes, mais les noms FIPS sont ceux qui comptent désormais pour la conformité réglementaire et les audits. Pour un panorama plus large de la discipline, notre dossier cryptographie regroupe l’ensemble de nos analyses sur le sujet.
En France, l’ANSSI a fixé une échéance à 2027 pour les systèmes les plus sensibles, ce qui pousse les équipes cryptographiques à évaluer dès maintenant quel algorithme intégrer dans leurs PKI. Le choix engage des années de compatibilité, de taille de certificat et de charge serveur : autant le poser sur des chiffres vérifiés plutôt que sur des suppositions.
ML-DSA (FIPS 204) : la norme généraliste héritée de Dilithium
ML-DSA descend directement de CRYSTALS-Dilithium, l’un des finalistes du concours PQC du NIST. Son fondement mathématique repose sur le problème Module-LWE (Learning With Errors sur des réseaux structurés), une famille de problèmes de réseaux euclidiens jugée difficile même pour un ordinateur quantique. Le NIST le désigne explicitement comme l’algorithme “principal” pour les signatures post-quantiques, celui à utiliser par défaut pour les certificats serveurs, les applications clientes et la majorité des cas d’usage.
ML-DSA se décline en trois jeux de paramètres, ML-DSA-44, ML-DSA-65 et ML-DSA-87, correspondant aux niveaux de sécurité NIST 2, 3 et 5 (approximativement équivalents à AES-128, AES-192 et AES-256). Les tailles de clés et de signatures restent modérées, de l’ordre de 1,3 à 2,6 Ko pour la clé publique et de 2,4 à 4,6 Ko pour la signature. Cette compacité relative, combinée à des temps de signature et de vérification rapides sur les processeurs modernes, explique pourquoi des banques testent déjà ML-DSA-65 pour sécuriser des flux de transactions à moyen terme.
Concrètement, ML-DSA-65 correspond au jeu de paramètres le plus cité dans les pilotes actuels, car il offre un niveau de sécurité catégorie 3, jugé suffisant pour la majorité des usages commerciaux, sans payer le surcoût de ML-DSA-87. Ce choix rejoint la logique déjà appliquée à AES-256 ou à ECDSA P-384 : le niveau de sécurité maximal existe, mais le niveau intermédiaire suffit dans la plupart des architectures et limite l’impact sur la bande passante et le stockage des certificats.
Le point faible de ML-DSA n’est pas la performance mais l’hypothèse mathématique elle-même. Les réseaux euclidiens structurés (Module-LWE) sont étudiés depuis moins de vingt ans, contre plusieurs décennies pour les fonctions de hachage. Ce n’est pas un risque théorique isolé : d’autres candidats post-quantiques ont déjà connu des révisions de sécurité en cours de route, comme le montre notre analyse de la fragilisation de Classic McEliece. Si une avancée en cryptanalyse des réseaux venait fragiliser ML-DSA, il faudrait une alternative reposant sur un fondement totalement différent. C’est précisément le rôle que joue SLH-DSA.
SLH-DSA (FIPS 205) : la sécurité de secours fondée sur le hachage
SLH-DSA reprend l’architecture de SPHINCS+, une signature dite “hash-based” : sa sécurité ne dépend que de la résistance des fonctions de hachage SHA-2 ou SHAKE, pas d’un problème de réseau. C’est un choix délibérément conservateur. Les fonctions de hachage résistent au calcul quantique avec une perte de sécurité prévisible (l’algorithme de Grover divise la sécurité par deux, pas plus), contrairement aux problèmes de réseaux dont la résistance quantique reste un sujet de recherche actif.
Cette robustesse a un coût direct sur la taille. SLH-DSA se décline en six jeux de paramètres principaux (SHA2-128s, 128f, 192s, 192f, 256s, 256f, déclinés aussi en variantes SHAKE), où le suffixe “s” privilégie des signatures compactes au prix d’une signature lente, et “f” privilégie la vitesse de signature au prix d’une signature volumineuse. Les clés publiques restent minuscules, de 32 à 64 octets, mais les signatures vont de 7 856 octets (128s) à 49 856 octets (256f) : jusqu’à 20 fois plus lourdes que ML-DSA-87.
Signer avec SLH-DSA est également beaucoup plus lent que signer avec ML-DSA, souvent de plusieurs ordres de grandeur selon les jeux de paramètres et le matériel utilisé. La vérification reste raisonnable, ce qui rend l’algorithme praticable pour des cas où l’on signe rarement mais où l’on vérifie souvent, comme les racines de confiance d’un certificat ou la signature d’un firmware. Pour affiner ce compromis, le NIST a publié le 13 avril 2026 un projet de document, SP 800-230, proposant des jeux de paramètres SLH-DSA supplémentaires pour les cas d’usage à nombre de signatures limité, dont la période de commentaires publics s’est achevée le 12 juin 2026.
Comprendre pourquoi SLH-DSA produit des signatures aussi volumineuses aide à juger s’il convient à un projet donné. L’algorithme construit une hypertree, une arborescence de multiples arbres de Merkle empilés, où chaque feuille signe la suivante jusqu’à la donnée finale. La signature doit inclure les chemins d’authentification à travers toute cette structure, d’où sa taille. C’est le prix d’une sécurité qui ne dépend que d’une fonction de hachage bien étudiée, sans hypothèse algébrique supplémentaire. Un lecteur familier des arbres de Merkle utilisés en blockchain reconnaîtra le principe, appliqué ici à la signature plutôt qu’à la preuve d’appartenance.
FN-DSA (Falcon) : la promesse d’un FIPS 206 encore en projet
FN-DSA dérive de Falcon, un schéma de signature basé sur les réseaux NTRU. Sélectionné par le NIST au même titre que ML-DSA et SLH-DSA, il ne bénéficie pas encore d’un statut final : au 10 septembre 2026, FIPS 206 reste un brouillon, avec une publication définitive attendue pour 2027. Il ne faut donc pas déployer FN-DSA en environnement réglementé validé FIPS tant que ce statut n’a pas changé.
L’intérêt de FN-DSA tient à sa compacité. FN-DSA-512 produit une signature d’environ 666 octets et une clé publique de 897 octets. FN-DSA-1024 monte à 1 280 octets de signature et 1 793 octets de clé publique. C’est nettement plus léger que ML-DSA-44 (2 420 octets de signature) et sans commune mesure avec SLH-DSA. Pour des protocoles où chaque octet compte, comme les objets connectés à bande passante limitée ou les certificats embarqués dans des flux à haute fréquence, cet avantage pèse lourd.
La contrepartie se situe côté implémentation. La signature Falcon repose sur de l’arithmétique en virgule flottante et sur un échantillonnage gaussien difficile à rendre constant en temps d’exécution, ce qui a historiquement rendu les implémentations sûres plus complexes à écrire que pour ML-DSA. Plusieurs analyses techniques publiées en 2025 et 2026 décrivent une signature FN-DSA plus lente que ML-DSA, tandis que la vérification reste compétitive. Tant que FIPS 206 n’est pas finalisé, FN-DSA reste un pari sur l’avenir plutôt qu’un choix de production.
Ce statut de brouillon n’empêche pas les équipes de recherche et certains fournisseurs de préparer le terrain. Le projet Open Quantum Safe maintient déjà une implémentation expérimentale de FN-DSA, ce qui permet de tester la compatibilité applicative avant la finalisation officielle, sans pour autant valider une mise en production réglementée. Cette approche, tester tôt sans déployer tôt, ressemble à la manière dont les équipes ont abordé ML-KEM avant que FIPS 203 ne soit finalisé en 2024 : les intégrations techniques étaient prêtes le jour de la publication du standard.
Tableau comparatif des spécifications techniques
Le tableau ci-dessous regroupe les tailles officielles publiées dans FIPS 204 et FIPS 205, ainsi que les tailles stables documentées pour FN-DSA dans les brouillons IETF et les présentations du NIST. Deux algorithmes classiques (RSA-2048 et ECDSA P-256) sont ajoutés en repère, pour mesurer l’écart avec la cryptographie pré-quantique encore majoritaire aujourd’hui.
| Algorithme | Statut NIST | Niveau de sécurité | Clé publique | Clé privée | Taille signature | Fondement |
|---|---|---|---|---|---|---|
| ML-DSA-44 | Final (FIPS 204) | Catégorie 2 | 1 312 o | 2 560 o | 2 420 o | Réseaux (Module-LWE) |
| ML-DSA-65 | Final (FIPS 204) | Catégorie 3 | 1 952 o | 4 032 o | 3 309 o | Réseaux (Module-LWE) |
| ML-DSA-87 | Final (FIPS 204) | Catégorie 5 | 2 592 o | 4 896 o | 4 627 o | Réseaux (Module-LWE) |
| SLH-DSA-SHA2-128s | Final (FIPS 205) | Catégorie 1 | 32 o | 64 o | 7 856 o | Hachage (SHA-2) |
| SLH-DSA-SHA2-128f | Final (FIPS 205) | Catégorie 1 | 32 o | 64 o | 17 088 o | Hachage (SHA-2) |
| SLH-DSA-SHA2-192s | Final (FIPS 205) | Catégorie 3 | 48 o | 96 o | 16 224 o | Hachage (SHA-2) |
| SLH-DSA-SHA2-192f | Final (FIPS 205) | Catégorie 3 | 48 o | 96 o | 35 664 o | Hachage (SHA-2) |
| SLH-DSA-SHA2-256s | Final (FIPS 205) | Catégorie 5 | 64 o | 128 o | 29 792 o | Hachage (SHA-2) |
| SLH-DSA-SHA2-256f | Final (FIPS 205) | Catégorie 5 | 64 o | 128 o | 49 856 o | Hachage (SHA-2) |
| FN-DSA-512 | Brouillon (FIPS 206) | Catégorie 1 | 897 o | 1 281 o | 666 o | Réseaux (NTRU) |
| FN-DSA-1024 | Brouillon (FIPS 206) | Catégorie 5 | 1 793 o | 2 305 o | 1 280 o | Réseaux (NTRU) |
| ECDSA P-256 (repère) | Pré-quantique | ~128 bits classiques | 64 o | 32 o | ~70-72 o | Courbes elliptiques |
| RSA-2048 (repère) | Pré-quantique | ~112 bits classiques | 256 o | ~1 190 o | 256 o | Factorisation |
Le contraste saute aux yeux : une signature ECDSA P-256 tient sur 70 octets, une signature ML-DSA-44 en prend 2 420, et une signature SLH-DSA-SHA2-256f en prend 49 856, soit environ 700 fois plus que la courbe elliptique. Cet écart n’est pas un détail d’implémentation, il détermine directement la taille des paquets TLS, la charge des certificats X.509 et la bande passante consommée par chaque poignée de main.
Benchmarks de performance : signature et vérification
Le NIST ne publie pas de tableau officiel de performance dans FIPS 204 ou FIPS 205. Ces documents fixent les tailles et la sécurité, pas la vitesse d’exécution, qui dépend du processeur, du compilateur et des instructions vectorielles disponibles. Les chiffres de performance viennent de trois familles de sources convergentes : le projet Open Quantum Safe (liboqs), qui maintient des implémentations de référence benchmarkées sur matériel x86-64, les analyses techniques publiées par des fournisseurs et chercheurs en 2025 et 2026, et les travaux académiques d’accélération matérielle.
Sur un cœur de processeur x86-64 optimisé, ML-DSA-44 signe et vérifie en sous-milliseconde, avec un débit de l’ordre de dizaines de milliers d’opérations par seconde. ML-DSA-65 et ML-DSA-87 restent dans le même ordre de grandeur, un peu plus lents à cause de paramètres plus grands, mais toujours largement praticables pour un serveur web à fort trafic. FN-DSA affiche une vérification comparable voire légèrement meilleure que ML-DSA-44 à taille de signature égale, mais une signature plus lente, souvent décrite comme 1,5 à 2 fois plus coûteuse en temps de calcul sur des implémentations optimisées comparables.
SLH-DSA change d’échelle. Signer avec les paramètres “s” (signature compacte) prend des dizaines à des centaines de millisecondes selon le niveau de sécurité, des ordres de grandeur au-dessus de ML-DSA et FN-DSA. Des travaux de recherche sur l’accélération matérielle de SLH-DSA montrent qu’il est possible de ramener ce temps à quelques millisecondes avec du silicium dédié, mais ces résultats restent expérimentaux et ne reflètent pas une implémentation logicielle standard. En pratique, SLH-DSA convient à des scénarios où l’on signe rarement (une racine de certification, un firmware publié une fois par trimestre) plutôt qu’à un serveur TLS qui négocie des milliers de connexions par seconde.
Ces ordres de grandeur expliquent pourquoi les trois algorithmes ne sont pas interchangeables malgré leur statut commun de “signature post-quantique standardisée”. Choisir uniquement sur la base de la sécurité théorique, sans tenir compte du profil de performance réel sur le matériel cible, conduit régulièrement à des déploiements qui fonctionnent en laboratoire mais s’effondrent sous charge réelle. Un test de charge avec le jeu de paramètres définitif, avant tout déploiement en production, reste la seule manière fiable de vérifier ces hypothèses.
Coût et disponibilité : où en sont les CA et le cloud
Contrairement à un chiffrement propriétaire, les trois algorithmes sont ouverts et implémentables sans redevance : leur code source figure dans liboqs, dans des forks expérimentaux d’OpenSSL et de BoringSSL, et progressivement dans les distributions Linux. Le vrai coût de la migration ne se trouve pas dans une licence logicielle mais dans le déploiement à l’échelle d’une PKI d’entreprise, un domaine où les grandes autorités de certification avancent avec prudence.
| Fournisseur / brique | Disponibilité au 09/2026 | Modèle tarifaire | Algorithmes couverts |
|---|---|---|---|
| Open Quantum Safe (liboqs) | Disponible, open source | Gratuit | ML-DSA, SLH-DSA, FN-DSA (expérimental) |
| OpenSSL (providers PQC) | Support progressif selon version | Gratuit | ML-DSA, SLH-DSA |
| DigiCert | Pilotes certificats hybrides | Sur devis, programme entreprise | ML-DSA, SLH-DSA (cas long terme) |
| Sectigo | Pilotes certificats hybrides | Sur devis, programme entreprise | ML-DSA |
| GlobalSign | Pilotes certificats hybrides | Sur devis, programme entreprise | ML-DSA, essais SLH-DSA archivage |
| AWS KMS | Non disponible en production | Non applicable | Aucun type de clé PQC publié |
| Google Cloud KMS | Non disponible en production | Non applicable | Aucun type de clé PQC publié |
| Azure Key Vault | Non disponible en production | Non applicable | Aucun type de clé PQC publié |
Aucun des trois grands fournisseurs de KMS cloud ne publie, à la date de cet article, de type de clé ML-DSA ou SLH-DSA en disponibilité générale, ni de grille tarifaire spécifique aux algorithmes post-quantiques. Du côté des autorités de certification, DigiCert, Sectigo et GlobalSign proposent toutes des programmes pilotes de certificats hybrides combinant un algorithme classique (ECDSA ou RSA) et un algorithme post-quantique, mais la tarification reste intégrée à des engagements entreprise sur mesure, sans liste de prix publique par certificat. Une entreprise qui veut tester ML-DSA aujourd’hui investit donc surtout du temps d’ingénierie, pas un budget de licence.
Ce flou tarifaire s’explique en grande partie par le volume encore limité de déploiements en production. Tant que les Baseline Requirements du CA/Browser Forum n’imposent rien, les CA n’ont pas de pression commerciale pour publier un tarif standardisé, et préfèrent négocier au cas par cas avec les grands comptes qui expérimentent. Les équipes qui budgétisent une migration en 2027 devraient donc prévoir une ligne “audit et intégration” plutôt qu’une ligne “licence algorithme”, et solliciter des devis directement auprès de leur CA actuelle pour obtenir un ordre de grandeur réaliste.
TLS 1.3 et l’intégration hybride post-quantique
La signature n’est qu’une moitié du problème post-quantique dans TLS. L’autre moitié, l’échange de clés, avance plus vite : des groupes hybrides comme X25519MLKEM768 et SecP256r1MLKEM768 combinent une courbe elliptique classique avec ML-KEM-768 (FIPS 203), et sont déjà négociés en production par plusieurs grands opérateurs de CDN et de navigateurs. Notre comparatif HQC vs ML-KEM détaille pourquoi le NIST a choisi de standardiser un second mécanisme d’échange de clés en complément de ML-KEM. Le brouillon IETF sur la conception hybride pour TLS 1.3 documente précisément ces combinaisons, et le RFC 9954 “Hybrid Key Exchange in TLS 1.3”, publié en juillet 2026 avec un statut informatif, en fixe le cadre technique.
Le chantier suivant concerne l’authentification, c’est-à-dire les certificats eux-mêmes. Passer un certificat X.509 en ML-DSA suppose que le CA/Browser Forum mette à jour ses Baseline Requirements, un processus attendu fin 2026 ou en 2027. Tant que ces règles ne changent pas, la plupart des déploiements post-quantiques observés restent hybrides côté échange de clés, et classiques côté signature de certificat. C’est un point que confondent souvent les équipes techniques : activer ML-KEM sur un serveur ne protège pas encore l’authentification du certificat, qui reste vulnérable tant qu’elle repose sur RSA ou ECDSA seuls.
Pour la France et l’Europe, cette distinction compte particulièrement : un opérateur qui coche la case “post-quantique” parce qu’il a activé un groupe hybride ML-KEM n’a traité que la moitié du risque. La signature des certificats, elle, dépendra du choix entre ML-DSA, SLH-DSA et, plus tard, FN-DSA.
Ce que les développeurs doivent savoir pour implémenter ces signatures
Le support logiciel de ML-DSA et SLH-DSA progresse rapidement depuis leur finalisation. OpenSSL propose un provider dédié à la cryptographie post-quantique à partir de ses versions récentes de la branche 3.x, permettant de générer des paires de clés ML-DSA ou SLH-DSA en ligne de commande sans dépendance externe. Le projet Open Quantum Safe fournit une implémentation de référence pour les trois algorithmes, y compris FN-DSA à titre expérimental, packagée pour C, Python, Java et Go. BouncyCastle, la bibliothèque cryptographique la plus utilisée côté JVM, a intégré ML-DSA et SLH-DSA dans ses versions récentes, et plusieurs forks expérimentaux de BoringSSL testent l’intégration côté navigateur.
Générer une paire de clés ML-DSA-65 avec un OpenSSL compatible PQC ressemble à ceci en ligne de commande :
openssl genpkey -algorithm ML-DSA-65 -out ml_dsa65_priv.pem
openssl pkey -in ml_dsa65_priv.pem -pubout -out ml_dsa65_pub.pem
openssl dgst -sign ml_dsa65_priv.pem -out message.sig message.txt
openssl dgst -verify ml_dsa65_pub.pem -signature message.sig message.txtLa syntaxe reste proche de ce qu’un développeur connaît déjà pour RSA ou ECDSA, ce qui simplifie l’apprentissage. Le vrai travail se situe ailleurs : dans l’audit des tailles de buffer codées en dur qui supposent une signature ECDSA de 70 octets, dans les limites de taille de paquet UDP pour les protocoles qui embarquent des certificats SLH-DSA, et dans les tests de charge qui révèlent l’impact réel d’une signature plus lourde sur une infrastructure existante. Ces problèmes ne sont pas cryptographiques, mais ce sont eux qui font échouer le plus de migrations en pratique.
5 cas d’usage réels de déploiement post-quantique
Au-delà de la théorie, cinq terrains illustrent où ML-DSA, SLH-DSA et FN-DSA sont réellement en train d’être testés ou déployés en 2026.
- Banques et paiements : plusieurs établissements testent ML-DSA-65 sur des infrastructures de test pour sécuriser des flux de transaction, un choix motivé par son équilibre entre taille de signature et vitesse de vérification. Ces pilotes servent aussi à mesurer l’impact sur des systèmes de compensation où la latence reste un critère contractuel.
- Autorités de certification : DigiCert, Sectigo et GlobalSign font tourner des programmes pilotes de certificats hybrides combinant algorithmes classiques et ML-DSA, avant l’arrivée des nouvelles Baseline Requirements. Ces pilotes visent surtout de grands clients entreprise qui veulent valider leur chaîne d’outils avant l’obligation réglementaire.
- Racines de confiance à durée de vie longue : les travaux du NIST autour de SP 800-230 visent des scénarios comme les racines de certification ou les clés de signature de firmware, où l’on signe rarement mais où la signature doit rester valide des décennies. C’est le terrain naturel de SLH-DSA, dont la taille de signature pèse peu face à une racine qui signe une poignée de certificats intermédiaires par an.
- Standardisation des formats : le groupe de travail IETF LAMPS intègre progressivement ML-DSA et SLH-DSA dans les formats X.509, CMS, JOSE et COSE, posant les fondations pour une adoption interopérable au-delà de TLS, notamment pour la signature de documents et les jetons d’authentification.
- Fournisseurs de CDN et navigateurs : le déploiement à grande échelle de groupes hybrides ML-KEM pour l’échange de clés côté TLS prépare le terrain technique et opérationnel pour l’arrivée ultérieure des signatures post-quantiques dans les mêmes infrastructures, en habituant les équipes d’exploitation à surveiller des poignées de main TLS plus volumineuses.
Guide de migration en 7 étapes vers la signature post-quantique
Migrer une PKI ou une chaîne de signature vers un algorithme post-quantique ne se fait pas en changeant une ligne de configuration. Voici une trajectoire réaliste pour une équipe de sécurité qui prépare l’échéance 2027.
- Cartographier les actifs cryptographiques. Recenser chaque usage de signature RSA ou ECDSA (certificats TLS, signature de code, VPN, authentification machine-à-machine) et estimer la durée de vie des données protégées.
- Prioriser par risque “harvest now, decrypt later”. Les données à longue durée de confidentialité ou d’intégrité (archives, dossiers médicaux, firmwares industriels) passent en premier.
- Adopter une bibliothèque agile en cryptographie. Intégrer liboqs ou un provider OpenSSL compatible PQC pour pouvoir basculer d’algorithme sans réécrire l’application.
- Choisir l’algorithme par cas d’usage. ML-DSA par défaut pour les certificats et l’authentification courante, SLH-DSA pour les racines de confiance et la signature de code à faible fréquence, FN-DSA une fois FIPS 206 finalisé pour les environnements à bande passante contrainte.
- Déployer en mode hybride. Combiner un algorithme classique et un algorithme post-quantique dans un même certificat ou une même négociation, pour garder une compatibilité descendante pendant la transition.
- Tester la charge serveur. Mesurer l’impact réel des signatures plus volumineuses sur la latence TLS et la consommation de bande passante, en particulier si SLH-DSA est envisagé.
- Suivre les échéances réglementaires. Aligner le calendrier interne sur les jalons ANSSI, NIST CNSA 2.0 et les futures Baseline Requirements du CA/Browser Forum, pour éviter un rattrapage en urgence.
Erreurs courantes à éviter pendant la migration
La première erreur consiste à traiter la migration comme un simple remplacement d’algorithme. Changer RSA en ML-DSA dans une configuration TLS ne suffit pas si les systèmes en aval (pare-feu applicatifs, équilibreurs de charge, appareils IoT anciens) imposent des limites de taille de paquet ou de certificat héritées de l’ère RSA et ECDSA. Un certificat ML-DSA-87 peut dépasser la taille qu’un ancien équipement réseau accepte dans un seul segment TCP, ce qui provoque des échecs de connexion difficiles à diagnostiquer.
La deuxième erreur consiste à choisir SLH-DSA par excès de prudence, sans mesurer l’impact réel sur la latence. Un jeu de paramètres “s” à catégorie 5 (SLH-DSA-SHA2-256s) peut convenir à une racine de certification, mais générerait une dégradation notable de performance s’il servait à signer chaque requête API dans un service à fort trafic. Le bon réflexe consiste à mesurer, pas à supposer, avant de figer un choix pour plusieurs années.
La troisième erreur consiste à ignorer le mode hybride. Déployer un algorithme post-quantique seul, sans le combiner à un algorithme classique éprouvé, expose à un risque si une faiblesse encore inconnue touchait le nouvel algorithme. Les recommandations actuelles de l’ANSSI et du NIST convergent vers l’hybridation comme étape intermédiaire obligatoire, pas comme option facultative.
Avantages et inconvénients de chaque algorithme
Aucun des trois algorithmes ne l’emporte sur tous les critères en même temps. Résumer leurs forces et leurs limites côte à côte aide à trancher rapidement en fonction du contexte : trafic à fort volume, archivage à très long terme, ou environnement embarqué contraint en mémoire.
ML-DSA : le choix par défaut
- Avantage : bon compromis taille, vitesse et sécurité, désigné norme principale par le NIST.
- Avantage : implémentations matures, déjà testées par des acteurs bancaires et des CA.
- Inconvénient : repose sur une hypothèse de réseaux relativement jeune en cryptanalyse.
- Inconvénient : signatures 30 à 65 fois plus lourdes qu’ECDSA P-256.
SLH-DSA : la police d’assurance
- Avantage : sécurité fondée uniquement sur le hachage, le fondement le plus conservateur disponible.
- Avantage : clés publiques minuscules, adaptées aux racines de confiance.
- Inconvénient : signatures très volumineuses, jusqu’à 49 856 octets.
- Inconvénient : signature lente, peu adaptée à un trafic TLS à fort volume.
FN-DSA : la compacité, sous réserve
- Avantage : signatures les plus compactes des trois, utiles en environnement contraint.
- Avantage : vérification rapide, comparable à ML-DSA.
- Inconvénient : FIPS 206 non finalisé au 10 septembre 2026, donc non éligible en environnement exigeant une validation FIPS.
- Inconvénient : implémentation constante en temps plus délicate à cause de l’arithmétique flottante.
Quel algorithme choisir : le verdict chiffré
Pour la grande majorité des déploiements, ML-DSA-65 s’impose comme le choix par défaut : standard finalisé depuis août 2024, signature de 3 309 octets qui reste gérable pour du TLS, et vitesse de signature sous-milliseconde qui ne dégrade pas la latence d’un serveur à fort trafic. C’est aussi l’algorithme le plus testé en conditions réelles, des pilotes bancaires aux certificats hybrides des grandes CA.
SLH-DSA garde sa place, mais dans un rôle précis : racine de confiance, signature de firmware, ou toute clé qui signe rarement et doit rester fiable même si une faille venait à toucher les réseaux euclidiens. Les nouveaux jeux de paramètres proposés dans SP 800-230 devraient réduire la taille des signatures pour ces cas d’usage limités, ce qui vaut la peine d’être suivi de près en 2027. Un argument souvent négligé joue aussi en sa faveur : dans une stratégie de défense en profondeur, combiner ML-DSA et SLH-DSA sur une même racine de confiance signifie qu’il faudrait casser deux fondements mathématiques indépendants, réseaux et hachage, pour compromettre la chaîne entière.
FN-DSA reste à surveiller plutôt qu’à déployer. Sa compacité en fait un candidat naturel pour l’IoT, les cartes à puce et les certificats embarqués dans des protocoles sensibles à la taille, mais la finalisation de FIPS 206 doit d’abord aboutir. Cinq recommandations concrètes par cas d’usage : pour les certificats TLS grand public, ML-DSA-65. Pour la signature de code et de firmware peu fréquente, SLH-DSA à paramètres “s”. Pour les racines de certification à très longue durée de vie, SLH-DSA en attendant les profils SP 800-230. Pour les objets connectés à bande passante limitée, FN-DSA une fois FIPS 206 finalisé. Pour les systèmes gouvernementaux et bancaires à haute assurance, un déploiement hybride associant ML-DSA à un algorithme classique.
Le point commun à toutes ces recommandations reste la même discipline : ne pas attendre l’échéance réglementaire pour lancer le premier pilote. Les trois algorithmes sont déjà implémentables, documentés et testables sans attendre une obligation légale. Les équipes qui commencent en 2026 arriveront à 2027 avec une migration déjà rodée plutôt qu’un projet d’urgence.
Questions fréquentes
ML-DSA, SLH-DSA et FN-DSA sont-ils déjà utilisables en production ?
ML-DSA et SLH-DSA sont finalisés depuis le 13 août 2024 et peuvent être déployés, notamment en mode hybride avec un algorithme classique. FN-DSA reste un brouillon (FIPS 206) et ne doit pas être utilisé dans un environnement exigeant une validation FIPS avant sa finalisation, attendue en 2027.
Pourquoi le NIST a-t-il standardisé plusieurs algorithmes de signature au lieu d’un seul ?
Pour éviter un point de défaillance unique. ML-DSA et FN-DSA reposent tous deux sur des problèmes de réseaux, tandis que SLH-DSA repose uniquement sur le hachage. Si une cryptanalyse future affaiblissait les réseaux structurés, SLH-DSA resterait disponible comme filet de sécurité.
Quel est l’impact des signatures post-quantiques sur la taille d’un certificat TLS ?
Un certificat signé en ML-DSA-65 alourdit la charge utile de plusieurs kilo-octets par rapport à ECDSA P-256. Avec SLH-DSA, l’écart grimpe à plusieurs dizaines de kilo-octets selon le jeu de paramètres, ce qui peut affecter la latence de la première poignée de main TLS sur des réseaux contraints.
Faut-il migrer directement vers un algorithme post-quantique pur, sans hybridation ?
Non, la quasi-totalité des déploiements observés en 2025 et 2026 restent hybrides, combinant un algorithme classique et un algorithme post-quantique. Cela garantit qu’une faiblesse encore inconnue dans les nouveaux algorithmes ne compromette pas la sécurité globale, tant que les Baseline Requirements des CA n’imposent pas un format purement post-quantique.
ML-DSA remplace-t-il aussi l’échange de clés ?
Non. ML-DSA (FIPS 204) est un algorithme de signature. L’échange de clés post-quantique repose sur ML-KEM (FIPS 203), déjà largement déployé en mode hybride dans TLS 1.3 via des groupes comme X25519MLKEM768. Les deux briques sont complémentaires et couvrent des besoins différents.
Quelle échéance s’applique en France pour la cryptographie post-quantique ?
L’ANSSI a fixé 2027 comme échéance pour intégrer la cryptographie post-quantique dans les systèmes les plus sensibles, avec une trajectoire qui s’étend au-delà pour le reste du parc. Les équipes techniques ont donc intérêt à lancer leurs pilotes de migration dès maintenant plutôt qu’à l’approche de la date limite.
SLH-DSA est-il trop lent pour un usage général ?
Pour un serveur TLS qui négocie des milliers de connexions par seconde, oui, la lenteur de signature de SLH-DSA le rend peu adapté. Pour une racine de certification qui signe quelques certificats intermédiaires par an, la lenteur de signature n’a aucun impact pratique, et la robustesse du fondement par hachage devient l’argument dominant.
Combien coûte une migration vers la signature post-quantique ?
Il n’existe pas de grille tarifaire standard, car les algorithmes eux-mêmes sont gratuits et open source. Le coût réel se concentre sur l’ingénierie : audit des systèmes existants, tests de compatibilité, mise à jour des bibliothèques cryptographiques et, le cas échéant, négociation d’un programme pilote avec une autorité de certification. Une entreprise qui commence tôt, avec une bibliothèque agile en cryptographie, répartit ce coût sur plusieurs mois plutôt que de l’absorber en urgence avant une échéance réglementaire.
