ML-DSA vs ECDSA : passer les signatures au post-quantique

ML-DSA vs ECDSA, c’est le volet signature de la transition post-quantique. ECDSA sur P-256 produit des signatures de 64 octets et se trouve partout, mais l’algorithme de Shor le casse. ML-DSA (FIPS 204, août 2024) résiste aux attaques quantiques connues et il est rapide, mais ses clés et ses signatures se mesurent en kilo-octets. Contrairement à l’échange de clés, où ML-KEM hybride est déjà le choix par défaut des navigateurs, la migration des signatures reste pour l’essentiel à venir.

Vue d’ensemble

Vitesses mesurées avec openssl speed sur un cœur d’Apple M4 Max. L’implémentation ML-DSA d’OpenSSL est écrite en C portable ; des implémentations optimisées signent plusieurs fois plus vite.

Pourquoi le changement est nécessaire

ECDSA repose sur le problème du logarithme discret sur les courbes elliptiques, que l’algorithme de Shor résout efficacement sur un grand ordinateur quantique tolérant aux fautes. Une telle machine n’existe pas encore, et les estimations de la date à laquelle elle pourrait exister varient fortement, mais les signatures ont une propriété qui détermine leur degré d’urgence : falsifier une signature plus tard n’annule pas une authentification passée. Un handshake TLS authentifié avec ECDSA en 2026 ne peut pas être attaqué rétroactivement, contrairement aux échanges de clés enregistrés. Ce qui demande en revanche une attention précoce, c’est tout ce dont les signatures doivent rester dignes de confiance pendant de nombreuses années : clés des AC racines et des AC intermédiaires, micrologiciels et chaînes de démarrage, racines de signature de code, documents juridiques et archives à long terme.

ML-DSA est une signature fondée sur les réseaux euclidiens (issue de CRYSTALS-Dilithium), dont la sécurité repose sur Module-LWE et Module-SIS, sans accélération quantique connue au-delà des accélérations génériques. NIST IR 8547 (un projet public initial) propose d’interdire ECDSA, EdDSA et RSA après 2035, et la CNSA 2.0 de la NSA exige ML-DSA-87 pour les systèmes de sécurité nationale, la signature des logiciels et des micrologiciels devant migrer en premier.

Le problème de la taille

C’est la taille qui rend la migration difficile. Un serveur TLS s’authentifie avec une chaîne de certificats et une signature du handshake ; avec ECDSA, les clés du certificat feuille et de l’intermédiaire, leurs signatures, deux SCT intégrés et la signature CertificateVerify totalisent quelques centaines d’octets. Avec ML-DSA-44, les mêmes éléments pèsent environ 14,7 Ko (deux clés publiques de 1312 octets et cinq signatures de 2420 octets : deux sur les certificats, deux dans les SCT et celle de CertificateVerify), et davantage avec ML-DSA-65. La première salve de messages du serveur dépasse alors la fenêtre de congestion TCP initiale, ce qui ajoute des allers-retours, et met à l’épreuve les limites d’amplification de QUIC.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
  if [ "$alg" = EC ]; then
    openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
    label="ECDSA P-256"
  else
    openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
    label="$alg"
  fi
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

ECDSA P-256  certificate   388 bytes
ML-DSA-44    certificate  3985 bytes
ML-DSA-65    certificate  5514 bytes

La réponse de la PKI du Web est encore en cours de conception. Chrome a annoncé en février 2026 qu’il prévoit de s’appuyer sur les Merkle Tree Certificates (un Internet-Draft du groupe PLANTS de l’IETF), qui remplacent la plupart des signatures propres à chaque certificat par de courtes preuves d’inclusion, et qu’il ne prévoit pas d’ajouter de certificats X.509 post-quantiques à son magasin de certificats racines actuel. Le CA/Browser Forum n’a pas encore approuvé ML-DSA pour les certificats TLS de confiance publique. Les PKI privées peuvent déjà émettre des certificats ML-DSA selon la RFC 9881, et OpenSSL 3.5 et versions ultérieures, Bouncy Castle et d’autres bibliothèques les prennent en charge.

Options hybrides et composites

Pendant la transition, de nombreux déploiements veulent des signatures que vérifient à la fois les anciens et les nouveaux clients, ou qui restent sûres si l’un des deux algorithmes est cassé :

• Les signatures composites (draft-ietf-lamps-pq-composite-sigs, encore à l’état d’Internet-Draft) définissent des algorithmes dotés d’un identifiant unique, comme ML-DSA-65 avec ECDSA P-256, dont la signature n’est valide que si ses deux composantes sont vérifiées. La RFC 9980 d’OpenPGP adopte la même approche avec ML-DSA-65+Ed25519, et OpenSSH 10.4 a ajouté un type de clé expérimental ML-DSA-44+Ed25519.
• Les signatures doubles joignent deux signatures indépendantes (CMS accepte plusieurs structures SignerInfo ; certains formats de document autorisent plusieurs champs de signature), ce qui permet à chaque vérificateur de contrôler celle qu’il comprend.
• Les PKI parallèles émettent à la fois des certificats classiques et post-quantiques et laissent les clients choisir : c’est le modèle que la négociation TLS prend déjà en charge via signature_algorithms.

Quand choisir l’un ou l’autre

• Certificats de serveur TLS publics, clés d’accès, OIDC et JWT publics : ECDSA (ou Ed25519) aujourd’hui ; suivez les travaux des navigateurs et de l’IETF pour la bascule.
• PKI privée pour des services et des appareils à longue durée de vie : ML-DSA-65, ou une signature composite ML-DSA plus ECDSA là où les deux types de vérificateurs coexistent.
• Micrologiciel et démarrage sécurisé : ML-DSA-87 ou les signatures fondées sur le hachage LMS, XMSS ou SLH-DSA, selon que vous avez besoin ou non de la conformité CNSA 2.0.
• Signature de code et de paquets : ajoutez ML-DSA à côté des signatures existantes à mesure que les écosystèmes (Sigstore, éditeurs de systèmes d’exploitation) le prennent en charge.
• Blockchains : le choix ne vous appartient pas ; des propositions de signatures post-quantiques existent pour plusieurs chaînes, mais aucune n’est largement déployée sur Bitcoin ou Ethereum.
• Jetons et sessions de courte durée : ECDSA reste adapté tant que les vérificateurs n’ont pas changé, puisque le risque de falsification n’existe qu’en temps réel.

Notes de migration

1. Inventoriez chaque clé de signature et chaque vérificateur (un inventaire cryptographique, ou CBOM, y aide), avec la durée de vie des clés et qui les vérifie.
2. Supprimez les hypothèses sur les tailles : colonnes de base de données, limites des en-têtes HTTP (une signature ML-DSA-65 fait environ 4,4 Ko en base64), stockage des cartes à puce, codes QR et enregistrements DNS.
3. Rendez les algorithmes négociables : identifiants d’algorithme dans les formats, listes d’autorisation dans les vérificateurs, et identifiants de clé permettant d’introduire de nouvelles clés à côté des anciennes.
4. Commencez par les racines à longue durée de vie : créez dès maintenant des racines et des intermédiaires ML-DSA ou composites pour les PKI privées, car la distribution des racines prend des années.
5. Testez les performances sur des chemins réels : latence du handshake avec des chaînes plus grandes, débit de signature (inférieur d’un ordre de grandeur à celui d’ECDSA en code portable), vérification sur des appareils contraints.
6. Surveillez l’état des normes FIPS et des politiques : FIPS 204 est finale, NIST IR 8547 n’est encore qu’un projet, les signatures composites en sont encore au stade de projet, et les règles de la WebPKI n’ont pas encore changé.

Références

• FIPS 204, norme de signature numérique fondée sur les réseaux modulaires
• FIPS 186-5, norme de signature numérique
• RFC 9881, ML-DSA dans X.509
• Projet public initial de NIST IR 8547
• draft-ietf-lamps-pq-composite-sigs (Internet-Draft)
• draft-ietf-plants-merkle-tree-certs (Internet-Draft)
• Programmes de certificats racines de Chrome, dont le programme résistant au quantique
• FAQ CNSA 2.0 de la NSA