Autorité de certification souveraine pour l'émission et la gestion de certificats à l'échelle de l'entreprise
Gestion du cycle de vie des certificats : découverte, gouvernance et automatisation
Domain Control Validation agnostique des DNS, prêt pour les certificats TLS de 47 jours
En août 2024, le NIST a finalisé les trois premières normes de cryptographie post-quantique : FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA). Ce guide est le pendant algorithmique de notre piste crypto-agilité : jeux de paramètres, tailles de clés et de signatures, et la syntaxe OpenSSL dont les praticiens ont réellement besoin.
Le 13 août 2024, le NIST a publié les trois premières normes de cryptographie post-quantique : FIPS 203 (ML-KEM) pour l'encapsulation de clés, FIPS 204 (ML-DSA) pour les signatures numériques et FIPS 205 (SLH-DSA) pour les signatures à base de hachage. Une quatrième norme, FIPS 206 (FN-DSA, dérivée de Falcon), est toujours à l'état de brouillon, et HQC a été retenu en mars 2025 comme KEM à base de codes pour diversifier un ensemble aujourd'hui presque entièrement à base de réseaux euclidiens. Ensemble, ces algorithmes constituent le socle qui remplacera RSA et la cryptographie sur courbes elliptiques dans TLS, S/MIME, la signature de code et le reste de la WebPKI au cours de la prochaine décennie.
La correspondance avec les algorithmes hérités est directe. ML-KEM remplace l'établissement de clés RSA et ECDH, ML-DSA remplace les signatures RSA et ECDSA, et SLH-DSA constitue un filet de sécurité délibérément conservateur, à base de hachage, pour les signatures à longue durée de vie pour lesquelles les hypothèses de sécurité des schémas à base de réseaux paraissent encore trop récentes. Chaque algorithme se décline en trois jeux de paramètres ciblant les catégories de sécurité 1, 3 et 5 du NIST — équivalentes à AES-128, AES-192 et AES-256 face à un attaquant quantique.
Ce guide est le compagnon de spécification du guide crypto-agilité et post-quantique. Il suppose une bonne familiarité avec la cryptographie à clé publique et s'adresse aux architectes, ingénieurs PKI et responsables sécurité qui ont besoin de savoir ce qu'est concrètement ML-KEM-768, quelle est la taille d'une signature ML-DSA sur le fil, et quand SLH-DSA justifie son coût bien plus élevé. La stratégie de migration, la découverte et l'inventaire appartiennent au guide parent ; ici, nous restons proches des normes, des chiffres et de l'outillage.
Le projet Post-Quantum Cryptography du NIST a été ouvert en 2016 par un appel public à propositions, s'est déroulé sur trois tours compétitifs, et a annoncé en juillet 2022 la première sélection d'algorithmes : Kyber pour l'encapsulation de clés, Dilithium et Falcon pour les signatures généralistes, et SPHINCS+ comme alternative à base de hachage. Deux années supplémentaires de normalisation ont suivi, et les schémas renommés ont été publiés comme normes FIPS finales le 13 août 2024. Falcon, rebaptisé FN-DSA, est toujours à l'état de brouillon dans FIPS 206 parce que son implémentation de signature en virgule flottante est difficile à rendre en temps constant de manière sûre. Un quatrième tour a retenu HQC en mars 2025 comme KEM à base de codes, afin de couvrir le risque d'une rupture imprévue dans la famille des réseaux qui domine déjà l'ensemble.
Le modèle de menace n'a pas changé. Un ordinateur quantique cryptographiquement pertinent exécutant l'algorithme de Shor casserait RSA et la cryptographie sur courbes elliptiques en temps polynomial, retirant du jour au lendemain les deux familles d'algorithmes qui sous-tendent aujourd'hui presque chaque poignée de main TLS, chaque signature S/MIME et chaque certificat de signature de code. Aucune estimation publique ne place cette machine dans les prochaines années, mais elle n'a pas besoin d'exister aujourd'hui pour avoir de l'importance. La stratégie « récolter maintenant, déchiffrer plus tard » (harvest-now, decrypt-later) est déjà viable pour tout adversaire disposant du budget de stockage pour conserver du trafic chiffré jusqu'à ce que le matériel rattrape son retard. Tout ce qui est signé aujourd'hui avec une fenêtre de validité longue — un certificat de CA racine, une image de firmware, un document notarié — doit également survivre à cet horizon.
Ce qui change avec la PQC, ce n'est pas si vous utilisez de la cryptographie, mais sur quelles structures mathématiques elle repose. Les schémas à base de réseaux euclidiens (ML-KEM et ML-DSA) tirent leur sécurité de variantes des problèmes Learning With Errors et Module-LWE. Les signatures à base de hachage (SLH-DSA) ne reposent que sur la résistance aux collisions et à la seconde préimage de fonctions de hachage standards — une hypothèse bien plus ancienne et bien plus conservatrice, au prix de signatures spectaculairement plus volumineuses. Le reste de ce guide reprend chaque algorithme à tour de rôle, puis met les tailles côte à côte et montre à quoi ressemble réellement la signature et la vérification en ligne de commande.
La convention de nommage mérite d'être retenue. ML-KEM et ML-DSA sont les deux familles à réseaux modulaires et ont été conçues par la même équipe que CRYSTALS-Kyber et CRYSTALS-Dilithium. SLH-DSA est à base de hachage et sans état (stateless), ce qui importe parce que les schémas à base de hachage antérieurs (XMSS, LMS, normalisés séparément dans la RFC 8391 et la RFC 8554) exigent du signataire qu'il garde trace des clés à usage unique déjà utilisées ; perdre cet état rompt la sécurité. SLH-DSA se passe de cette comptabilité au prix de signatures plus volumineuses.
Module-Lattice-Based Key-Encapsulation Mechanism. Remplace RSA et ECDH partout où deux parties doivent s'accorder sur une clé symétrique partagée. Trois jeux de paramètres : ML-KEM-512 (catégorie de sécurité 1, ~AES-128), ML-KEM-768 (catégorie 3, ~AES-192), ML-KEM-1024 (catégorie 5, ~AES-256). Les clés publiques vont de 800 B à 1568 B ; les cryptogrammes de 768 B à 1568 B. Rapide sur les CPU généralistes et favorable à une implémentation en temps constant, ce qui explique pourquoi tous les éditeurs de navigateurs s'en sont saisis en premier.
Module-Lattice-Based Digital Signature Algorithm. Le remplaçant par défaut des signatures RSA et ECDSA dans les certificats et les protocoles. Trois jeux de paramètres : ML-DSA-44 (catégorie de sécurité 2), ML-DSA-65 (catégorie 3), ML-DSA-87 (catégorie 5). Les clés publiques vont de 1312 B à 2592 B ; les signatures de 2420 B à 4627 B. La signature et la vérification sont un ordre de grandeur plus lentes qu'ECDSA, mais restent largement dans les budgets pratiques de presque tous les workloads.
Stateless Hash-Based Digital Signature Algorithm. Une alternative délibérément conservatrice dont la sécurité ne repose que sur la fonction de hachage. Douze jeux de paramètres, répartis sur deux familles (SHA2 et SHAKE) et deux profils par niveau de sécurité : les variantes -s (small) minimisent la taille de signature au prix d'une signature plus lente, les variantes -f (fast) font l'inverse. Les signatures vont d'environ 7,8 Ko (SLH-DSA-128s) à plus de 49 Ko (SLH-DSA-256f). SLH-DSA prend sa place là où les hypothèses des réseaux euclidiens paraissent encore trop récentes : CA racines à longue durée de vie, firmware, signatures d'archive.
FN-DSA (Falcon, brouillon FIPS 206) est le schéma de signature à base de réseaux à signature plus compacte — environ 666 B en catégorie 1 — mais son implémentation de référence utilise une arithmétique en virgule flottante difficile à rendre en temps constant sur la diversité du matériel qui signe des certificats. HQC a été sélectionné au tour 4 (mars 2025) comme KEM à base de codes destiné à diversifier l'ensemble, afin qu'une rupture mathématique unique ne mette pas hors course toute la pile PQ.
La primitive d'accord de clé PQ de référence. Dans TLS 1.3, elle est désormais déployée sous le nom X25519MLKEM768, un partage de clé hybride qui exécute X25519 classique et ML-KEM-768 en parallèle et combine leurs sorties pour dériver le secret de la poignée de main (le draft IETF `draft-ietf-tls-ecdhe-mlkem` du groupe de travail TLS définit le groupe nommé ; la RFC 9794 fixe la terminologie hybride). Chrome et Edge l'activent par défaut pour la majorité des utilisateurs ; Cloudflare et d'autres grands CDN l'acceptent côté serveur. C'est la seule primitive PQ que la plupart des opérateurs verront en trafic réel en 2026.
Le remplaçant par défaut des signatures pour les certificats, S/MIME, la signature de code, les JWT et la longue traîne de « tout ce qui utilise aujourd'hui RSA ou ECDSA ». Le groupe de travail LAMPS profile activement son usage dans X.509 (draft-ietf-lamps-dilithium-certificates), et Cloudflare, Microsoft et Google ont tous publié des émissions expérimentales de certificats ML-DSA depuis des CA internes.
L'outil adapté lorsqu'une signature doit rester vérifiable pendant des décennies sur des hypothèses qui ne dépendent pas de la tenue des problèmes de réseaux. Ses terrains naturels : auto-signatures de CA racines, ancres de secure boot, clés de mise à jour de firmware, notarisation d'enregistrements immuables. La taille des signatures SLH-DSA la rend inadaptée au TLS à fort volume ou à la signature par requête, mais sans importance pour les cas d'usage « signer une fois, vérifier souvent ».
Pour les prochaines années, le déploiement réaliste est hybride : un échange de clé ou une signature classique aux côtés d'un équivalent PQ, tous deux vérifiés, la connexion n'aboutissant que lorsque les deux passent. La surface hybride est celle où TLS 1.3 se trouve déjà (X25519MLKEM768), celle vers laquelle LAMPS oriente X.509 (draft-ietf-lamps-pq-composite-sigs), et celle vers laquelle des régulateurs comme l'ANSSI recommandent explicitement de démarrer les nouveaux déploiements.
La différence pratique la plus importante entre les nouveaux algorithmes et les anciens est la taille sur le fil. Les clés et signatures RSA-3072 et ECDSA P-256 se mesurent en centaines d'octets ; les schémas à base de réseaux sont un ordre de grandeur plus volumineux, et SLH-DSA en est deux. La planification capacitaire en bordure de réseau — tailles d'enregistrements TLS, entrées de logs CT, paquets de certificats dans les images de conteneurs — doit en tenir compte.
Quelques-uns de ces chiffres méritent un second regard. Les signatures ML-DSA-65 font environ 50 fois la taille d'une signature ECDSA P-256 et environ neuf fois celle d'une signature RSA-3072, ce qui signifie que chaque poignée de main TLS utilisant ML-DSA ajoute plusieurs kilo-octets supplémentaires par certificat sur le fil — et une chaîne de certificats complète avec trois ou quatre certificats signés en ML-DSA ajoute des dizaines de kilo-octets. Les signatures SLH-DSA-128s font environ 120 fois une signature ECDSA P-256 ; SLH-DSA-128f, plus de 260 fois. Le suffixe « s » optimise la taille et le paie en temps de signature ; « f » optimise la vitesse de signature et le paie en taille. Pour une signature de racine unique, optez presque toujours pour « s » ; pour quoi que ce soit qui signe plus qu'occasionnellement, « f ».
Les chiffres de vitesse racontent une histoire plus rassurante. L'encapsulation et la décapsulation ML-KEM-768 sont toutes deux plus rapides que X25519 sur la plupart du matériel moderne, et la vérification ML-DSA-65 est compétitive avec la vérification RSA-3072. La signature SLH-DSA est véritablement lente — dizaines à centaines de millisecondes sur des CPU généralistes — mais sa vérification est rapide, ce qui est l'essentiel pour les charges « signer une fois, vérifier souvent ».
| Algorithme | Clé publique | Signature / cryptogramme | Classe de vitesse | Compatible matériel |
|---|---|---|---|---|
| RSA-3072 | 384 B | 384 B | Signature lente, vérification rapide | Mature, prise en charge HSM ubiquitaire |
| ECDSA P-256 | 64 B | 64 B | Rapide des deux côtés | Mature, prise en charge HSM ubiquitaire |
| ML-KEM-768 | 1184 B | 1088 B (cryptogramme) | Très rapide des deux côtés | Favorable au temps constant, logiciel uniquement dans un premier temps |
| ML-DSA-65 | 1952 B | 3293 B | Vérification rapide, signature plus lente | Prise en charge HSM limitée en 2026 |
| SLH-DSA-128s | 32 B | ~7856 B | Signature très lente | Hachage seul, compatible avec les accélérateurs de hachage existants |
| SLH-DSA-128f | 32 B | ~17088 B | Signature plus rapide, sig plus volumineuse | Hachage seul, compatible avec les accélérateurs de hachage existants |
OpenSSL 3.5 (sorti en avril 2025) est la première version amont à embarquer ML-KEM, ML-DSA et SLH-DSA dans le provider par défaut, donc les commandes ci-dessous supposent un build moderne. Sur les systèmes plus anciens, les mêmes algorithmes sont disponibles via le provider OQS chargé sur OpenSSL 3.x ; les chaînes d'algorithmes sont les mêmes mais la configuration ne l'est pas, vérifiez donc toujours `openssl list -providers -kem-algorithms` et `openssl list -signature-algorithms` sur le binaire que vous exécutez réellement.
Les options `-text -noout` impriment la clé analysée, ce qui sert à confirmer que l'OID d'algorithme écrit dans le fichier correspond à celui qu'attend le consommateur du certificat. Si votre sortie ne montre la clé qu'en octets bruts, le build que vous exécutez précède la prise en charge de l'impression texte de ML-DSA — repliez-vous alors sur `openssl asn1parse` pour inspecter la structure SubjectPublicKeyInfo.
# Vérifier que le provider expose bien ML-DSA / ML-KEM / SLH-DSA sur ce build
openssl list -providers
openssl list -signature-algorithms | grep -Ei 'ML-DSA|SLH-DSA'
openssl list -kem-algorithms | grep -i ML-KEM
# Générer une paire de clés ML-DSA-65 (FIPS 204, catégorie de sécurité 3)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
# Inspecter la moitié publique — notez l'OID d'algorithme et la clé bien plus volumineuse
openssl pkey -in mldsa65.key -pubout -text -nooutLa surface de signature est volontairement la même que pour tout autre algorithme de clé sous OpenSSL : `pkeyutl` avec `-sign` et `-verify`, l'algorithme provient de la clé. La commande de vérification ci-dessous génère également une clé SLH-DSA-128s aux côtés de ML-DSA-65, afin que les tailles de signature sur disque puissent être comparées directement avec `ls -l`.
La chaîne d'algorithme exacte pour SLH-DSA dépend du provider — FIPS 205 définit des jeux de paramètres paramétrés par famille de hachage (SHA2 vs SHAKE) et par profil (s vs f), et toutes les implémentations n'exposent pas les mêmes noms. Si `SLH-DSA-SHA2-128s` est rejeté, essayez `SLH-DSA-128s`, `slh-dsa-sha2-128s`, ou ce qui apparaît dans `openssl list -signature-algorithms` (la syntaxe dépend du provider — vérifiez `openssl list -providers -kem-algorithms` pour les noms de KEM correspondants).
# Aller-retour avec ML-DSA-65
echo "post-quantum payload" > msg.bin
openssl pkeyutl -sign -inkey mldsa65.key -rawin -in msg.bin -out msg.mldsa65.sig
openssl pkeyutl -verify -inkey mldsa65.key -rawin -in msg.bin -sigfile msg.mldsa65.sig
# -> Signature Verified Successfully
# Même aller-retour avec SLH-DSA-128s (FIPS 205, profil "small")
openssl genpkey -algorithm SLH-DSA-SHA2-128s -out slhdsa128s.key
openssl pkeyutl -sign -inkey slhdsa128s.key -rawin -in msg.bin -out msg.slhdsa128s.sig
openssl pkeyutl -verify -inkey slhdsa128s.key -rawin -in msg.bin -sigfile msg.slhdsa128s.sig
# Comparer les tailles sur disque — la signature SLH-DSA fait ~7,8 Ko vs ~3,3 Ko pour ML-DSA
ls -l msg.mldsa65.sig msg.slhdsa128s.sigLa décision est presque toujours dictée par le contexte : protocole, durée de vie de la clé, posture réglementaire. Les cinq règles ci-dessous couvrent les cas qui se présentent en pratique.
Pour tout nouveau déploiement TLS, IPsec, SSH ou QUIC en 2026, le bon choix d'échange de clés est le named group hybride X25519MLKEM768 utilisé dans TLS 1.3 — le draft IETF `draft-ietf-tls-ecdhe-mlkem` du groupe de travail TLS définit le groupe nommé ; la RFC 9794 fixe la terminologie hybride — et déjà adopté par Chrome et Edge. La construction hybride garantit que la connexion est au moins aussi sûre que X25519 classique même si ML-KEM est cassé plus tard, pour un coût d'environ 1,1 Ko supplémentaire dans le ClientHello. C'est le contrôle PQ le moins cher que vous puissiez déployer et il neutralise directement le « harvest-now, decrypt-later » sur les nouvelles sessions.
Partout où vous auriez tendu la main vers RSA ou ECDSA — signature de certificats, émission de JWT, signature de code, S/MIME, signature de documents — ML-DSA est le remplaçant PQ par défaut. Prévoyez 50 à 100 fois la taille de signature d'ECDSA. Ce coût est supportable pour toutes les charges sauf les plus sensibles à la bande passante des signatures (entrées de logs CT, signatures de taille d'en-tête dans des protocoles contraints), mais il doit être anticipé. Le profil X.509 du groupe LAMPS (draft-ietf-lamps-dilithium-certificates) est le document à suivre si vous construisez votre propre PKI.
Si une signature doit rester vérifiable pendant plus de 20 ans, ou si votre politique de sécurité exige explicitement une cryptographie hors réseaux euclidiens, SLH-DSA est la réponse. Ses terrains naturels : auto-signatures de CA racines, ancres de secure boot, clés de mise à jour de firmware, archivage d'enregistrements notariés. Choisissez le jeu de paramètres -s pour des signatures uniques (plus petit, plus lent) ; choisissez -f si la cadence de signature dépasse quelques signatures par minute. SLH-DSA est aussi l'algorithme de choix lorsque vous avez besoin d'une signature PQ que votre HSM peut déjà accélérer — chaque octet d'une signature SLH-DSA est la sortie d'une fonction de hachage standard.
Pour les 3 à 7 prochaines années, le déploiement réaliste est hybride : classique + PQ en parallèle, tous deux vérifiés, la connexion ou la signature n'étant valide que lorsque les deux passent. C'est le modèle déjà déployé dans TLS 1.3 avec X25519MLKEM768, et celui que le groupe de travail LAMPS profile pour X.509 dans draft-ietf-lamps-pq-composite-sigs. L'hybride protège contre une rupture précoce dans l'une ou l'autre famille, au prix d'une bande passante doublée et d'un temps de vérification approximativement doublé. Une fois la confiance dans les schémas PQ mûrie et les algorithmes classiques formellement obsolétisés, les enveloppes hybrides tomberont — mais prévoyez que la transition elle-même occupera l'essentiel du reste de la décennie.
Le mode d'échec le plus courant des migrations PQ est de commencer par l'algorithme et non par la liste d'actifs. Avant tout basculement, exécutez une découverte et un inventaire complets : chaque certificat, chaque clé embarquée, chaque service signant des JWT, chaque chaîne de signature de code. À partir de là, priorisez par exposition (tout ce qui est signé pour plus de 5 ans, tout ce qui déchiffre du trafic récolté) et migrez dans l'ordre découvrir → prioriser → hybride → bascule. La stratégie et la gouvernance de ce travail vivent dans le guide crypto-agilité et post-quantique ; celui-ci reste sur les algorithmes eux-mêmes.
Préparation PQC orientée découverte via /audit-pqc — l'audit PQC gratuit d'Evertrust parcourt votre parc et produit une liste priorisée de certificats et de services de signature exposés au « harvest-now, decrypt-later » et au risque quantique de longue validité. C'est le bon premier pas avant tout choix d'algorithme, et le rapport est structuré pour alimenter directement un plan de migration aligné sur les normes décrites dans ce guide.
Émission et renouvellement agnostiques vis-à-vis de l'algorithme — Evertrust PKI et CLM sont conçus autour de l'algorithme, pas vissés à un seul. Les mêmes workflows d'enrôlement, d'approbation et de renouvellement que vous exécutez aujourd'hui pour les certificats RSA et ECDSA tourneront sans changement pour les certificats ML-DSA, SLH-DSA et hybrides à mesure que les profils CA correspondants se stabiliseront. Vous changez une politique, pas une plateforme.
Voies de certificats hybrides pendant la transition — pour la période pluri-annuelle où les signatures classiques et PQ devront cohabiter, Evertrust suit les profils LAMPS de signatures composites hybrides à mesure qu'ils se stabilisent, pour que la bascule de l'hybride vers le PQ pur soit un changement de politique, pas une réimplémentation. Un inventaire, un moteur de politique, un seul endroit pour prouver aux auditeurs que la migration est sur les rails.