ML-DSA vs SLH-DSA : signatures à réseaux ou à hachage

ML-DSA vs SLH-DSA, c’est le principal choix parmi les signatures post-quantiques normalisées par le NIST, toutes deux publiées le 13 août 2024. ML-DSA (FIPS 204, issu de CRYSTALS-Dilithium) repose sur des réseaux euclidiens structurés ; SLH-DSA (FIPS 205, issu de SPHINCS+) ne repose que sur la sécurité de sa fonction de hachage. Leurs profils de taille et de vitesse sont si différents que la plupart des systèmes utiliseront ML-DSA, et SLH-DSA là où ses hypothèses prudentes justifient le coût.

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, et des implémentations optimisées signent plusieurs fois plus vite.

Hypothèses de sécurité

ML-DSA est un schéma fondé sur les réseaux euclidiens, construit selon l’approche Fiat–Shamir avec abandons (Fiat–Shamir with aborts). Sa sécurité repose sur les problèmes d’apprentissage avec erreurs sur modules (Module Learning With Errors) et de solution entière courte sur modules (Module Short Integer Solution), étudiés depuis une vingtaine d’années, qui ont résisté aux attaques classiques comme quantiques, mais dont les estimations de sécurité concrète évoluent encore à mesure que les techniques de réduction de réseaux progressent. Le NIST a choisi des jeux de paramètres dotés de marges par rapport à ces estimations.

SLH-DSA construit ses signatures à partir de signatures fondées sur le hachage à usage unique et à usage limité, organisées en hyperarbre. Tant que SHA-256 ou SHAKE256 conservent leur résistance à la préimage et les propriétés apparentées, SLH-DSA reste sûr ; il n’y a aucune structure algébrique à attaquer. C’est donc la signature la plus prudente que le NIST ait normalisée, et la couverture naturelle si une percée contre les réseaux euclidiens survenait un jour. Contrairement aux schémas de signature avec état fondés sur le hachage, LMS et XMSS, il n’a besoin d’aucun état : chaque clé peut signer jusqu’à 2⁶⁴ messages.

Tailles et vitesse en pratique

Le script ci-dessous signe le même message avec chaque algorithme à l’aide d’OpenSSL 3.6.5.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
printf 'firmware-2026.10.bin digest' > msg
for alg in ML-DSA-44 ML-DSA-65 SLH-DSA-SHA2-128s SLH-DSA-SHA2-128f ED25519; do
  openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
  openssl pkeyutl -sign -rawin -inkey key.pem -in msg -out sig.bin 2>/dev/null
  openssl pkey -in key.pem -pubout -outform DER -out pub.der 2>/dev/null
  openssl pkey -in key.pem -pubout -out pub.pem 2>/dev/null
  if openssl pkeyutl -verify -rawin -pubin -inkey pub.pem -in msg -sigfile sig.bin >/dev/null 2>&1; then ok=yes; else ok=no; fi
  printf '%-18s public key (SPKI DER) %5s bytes, signature %6s bytes, verifies: %s\n' "$alg" \
    "$(wc -c < pub.der | tr -d ' ')" "$(wc -c < sig.bin | tr -d ' ')" "$ok"
done
cd / && rm -rf "$dir"

ML-DSA-44          public key (SPKI DER)  1334 bytes, signature   2420 bytes, verifies: yes
ML-DSA-65          public key (SPKI DER)  1974 bytes, signature   3309 bytes, verifies: yes
SLH-DSA-SHA2-128s  public key (SPKI DER)    50 bytes, signature   7856 bytes, verifies: yes
SLH-DSA-SHA2-128f  public key (SPKI DER)    50 bytes, signature  17088 bytes, verifies: yes
ED25519            public key (SPKI DER)    44 bytes, signature     64 bytes, verifies: yes

Les deux profils sont à l’opposé l’un de l’autre. ML-DSA a des clés publiques et des signatures de l’ordre du kilo-octet, et signe des milliers de fois par seconde. SLH-DSA a des clés publiques minuscules (aussi petites que celles d’Ed25519), mais des signatures de 8 à 50 Ko, et ses jeux compacts s demandent environ 137 ms par signature sur cette machine (les jeux f échangent une taille de signature doublée contre une signature environ 20 fois plus rapide). La vérification est rapide pour les deux. Pour une chaîne de certificats ou un handshake TLS, ML-DSA est utilisable et SLH-DSA ne l’est pas ; pour une image de micrologiciel signée une fois par version et vérifiée à chaque démarrage, le coût de SLH-DSA est sans importance, et sa minuscule clé publique tient dans la ROM de démarrage.

Détails opérationnels

• Signature hedged. Les deux normes mélangent par défaut un aléa frais à des valeurs dérivées de la clé et autorisent une variante déterministe pour les plateformes dépourvues de générateur de nombres aléatoires ; les vérificateurs ne peuvent pas faire la différence.
• Contextes. Les deux lient à chaque signature une chaîne de contexte d’au plus 255 octets, que les protocoles devraient utiliser pour séparer les usages.
• Variantes pure et avec pré-hachage. HashML-DSA et HashSLH-DSA signent un condensat en y liant l’OID de la fonction de hachage ; ce sont des algorithmes distincts, avec des OID distincts, et FIPS 204 recommande de n’utiliser une clé que pour l’une des deux variantes.
• Formats de clé privée. Les clés ML-DSA peuvent être stockées sous forme de graine de 32 octets, ce que la RFC 9881 autorise dans ses encodages seed ou both ; des problèmes d’interopérabilité surviennent quand une partie attend la clé étendue.
• Matériel et validation FIPS. Des modules validés intégrant ML-DSA et SLH-DSA sont apparus à partir de 2024 ; vérifiez dans le certificat du module les jeux de paramètres exacts.

Quand choisir l’un ou l’autre

• PKI privée, mTLS interne, signature de code et de documents : ML-DSA-65 (ou 44).
• Micrologiciel, démarrage sécurisé, racines de confiance matérielles : SLH-DSA-128s ou 192s, ou les schémas avec état LMS et XMSS, qu’impose CNSA 2.0 pour ce cas, si vous savez gérer l’état du signataire.
• Archives à long terme et certificats racines censés durer des décennies : SLH-DSA, éventuellement aux côtés de ML-DSA sous forme de signature double.
• Signature à haut volume (jetons, transactions, journaux) : ML-DSA ; SLH-DSA ne peut pas suivre.
• Protocoles à bande passante limitée : aucun des deux n’est petit ; ML-DSA-44 est aujourd’hui l’option normalisée la plus compacte, et FN-DSA (projet de FIPS 206) vise plus bas.
• TLS de la WebPKI publique : aucun des deux n’est accepté par les navigateurs aujourd’hui ; consultez ML-DSA vs ECDSA pour une vue d’ensemble de la transition.

Notes de migration

1. Inventoriez les usages de signature par durée de vie et par volume : les artefacts à longue durée de vie et rarement signés sont candidats à SLH-DSA ; tout le reste, à ML-DSA.
2. Choisissez des versions de bibliothèques qui implémentent les normes finales : OpenSSL 3.5 ou ultérieur (avril 2025), Bouncy Castle pour Java 1.79 ou ultérieur (1.81 pour l’encodage normalisé de la clé privée), crypto/mldsa de Go 1.27 pour ML-DSA. Les sorties de Dilithium et de SPHINCS+ antérieures à la normalisation ne sont pas compatibles.
3. Prévoyez la taille : augmentez les limites des champs de certificat, de jeton et de signature ; les certificats ML-DSA-65 font environ 5,5 Ko (voir la comparaison associée) et les signatures SLH-DSA peuvent dépasser les limites courantes des en-têtes ou des enregistrements.
4. Envisagez des hybrides pendant la transition : des certificats composites ML-DSA plus ECDSA ou EdDSA (un Internet-Draft de l’IETF) ou des signatures doubles permettent aux vérificateurs classiques de continuer à fonctionner.
5. Fixez la chaîne de contexte et la variante (pure ou avec pré-hachage) dans la spécification de votre protocole, afin que toutes les implémentations concordent.

Références

• FIPS 204, norme de signature numérique fondée sur les réseaux modulaires
• FIPS 205, norme de signature numérique sans état fondée sur le hachage
• RFC 9881, ML-DSA dans X.509
• RFC 9909, SLH-DSA dans X.509
• NIST SP 800-208, signatures fondées sur le hachage avec état
• Projet public initial de NIST IR 8547