ML-DSA (FIPS 204) et SLH-DSA (FIPS 205)

ML-DSA (algorithme de signature numérique fondé sur des réseaux modulaires), normalisé sous le nom de FIPS 204, est dérivé de CRYSTALS-Dilithium. Dilithium a été conçu par Ducas, Kiltz, Lepoint, Lyubashevsky, Schwabe, Seiler et Stehle, puis soumis à NIST en 2017. Il utilise le cadre Fiat-Shamir avec rejets, appliqué à Module-LWE, pour produire un schéma de signature pratique doté de solides preuves de sécurité.

Les transformations de Fiat-Shamir convertissent les protocoles interactifs d’identification en signatures. Pour les schémas fondés sur des réseaux, une application directe révèle des informations sur la clé privée par l’intermédiaire du vecteur de réponse. La technique « avec rejets » de Lyubashevsky ajoute un échantillonnage par rejet : le signataire vérifie si la réponse révélerait des informations, puis abandonne et recommence si c’est le cas. Cela entraîne un léger surcoût lors de la signature, mais cette étape est essentielle à la sécurité.

Pour signer, ML-DSA échantillonne un vecteur de masquage y selon une distribution uniforme, calcule un engagement w = Ay, hache (message, w) pour obtenir un polynôme de défi c et calcule la réponse z = y + cs. L’échantillonnage par rejet vérifie si z révèle des informations sur s. Si la vérification réussit, la signature est (c, z), accompagnée d’un indice pour accélérer la vérification. Sinon, le processus recommence.

ML-DSA définit trois jeux de paramètres : ML-DSA-44 (niveau de sécurité 2 de NIST, environ 128 bits), ML-DSA-65 (niveau 3, environ 192 bits) et ML-DSA-87 (niveau 5, environ 256 bits). Les nombres font référence aux rangs des modules dans le schéma. Les tailles des clés publiques sont respectivement de 1312, 1952 et 2592 octets. La taille d’une signature ML-DSA-65 est de 3293 octets, contre 64 octets pour Ed25519 à 128 bits de sécurité.

Le principal inconvénient de ML-DSA par rapport à ECDSA ou EdDSA est la taille des signatures. Les signatures ML-DSA-65 font 3293 octets, contre 64 octets pour Ed25519. Pour les protocoles qui transmettent de nombreuses signatures (chaînes de certificats TLS, signature de code), cela augmente la bande passante. Toutefois, la signature et la vérification de ML-DSA sont très rapides (comparables ou plus rapides que celles d’ECDSA), de sorte que le compromis concerne principalement le coût des communications.

SLH-DSA (algorithme de signature numérique sans état fondé sur le hachage), normalisé sous le nom de FIPS 205, est dérivé de SPHINCS+. Contrairement aux schémas fondés sur des réseaux, la sécurité de SLH-DSA repose uniquement sur la résistance aux collisions et aux secondes préimages de la fonction de hachage sous-jacente (SHA-256 ou SHAKE-256). Cela rend SLH-DSA extrêmement prudent : il reste sûr même si les hypothèses liées aux réseaux sont compromises.

SLH-DSA repose sur WOTS+ (signature à usage unique de Winternitz), un schéma fondé sur le hachage dans lequel la clé privée est un ensemble de chaînes aléatoires et la clé publique est obtenue en hachant plusieurs fois chacune d’elles. La signature consiste à appliquer partiellement le hachage en fonction des bits du message. WOTS+ ne peut être utilisé qu’une seule fois par paire de clés en toute sécurité ; le réutiliser deux fois révèle des informations. SLH-DSA permet la signature répétée grâce à des arbres construits au-dessus de WOTS+.

SLH-DSA utilise un hyperarbre : un arbre composé d’arbres de Merkle. Chaque feuille est la clé publique d’une instance WOTS+. La racine est la clé publique de SLH-DSA. Une signature comprend la signature WOTS+ du message et le chemin d’authentification allant de la feuille à la racine. La structure en hyperarbre permet de produire de nombreuses signatures à partir d’une seule paire de clés en utilisant différentes feuilles WOTS+.

SLH-DSA compte 12 jeux de paramètres combinant la fonction de hachage (SHA-256 ou SHAKE-256), le niveau de sécurité (128s/128f, 192s/192f, 256s/256f) et l’optimisation (s = petites signatures, f = signature rapide). La variante 128f produit des signatures de 7856 octets et permet une signature rapide ; la variante 128s produit également des signatures de 7856 octets, mais plus lentement. Toutes sont bien plus volumineuses que celles de ML-DSA, mais reposent sur l’hypothèse de sécurité la plus robuste possible.

ML-DSA est privilégié lorsque les performances et la bande passante importent et que l’on fait confiance aux hypothèses liées aux réseaux. SLH-DSA est privilégié pour les déploiements extrêmement prudents où seule la sécurité des fonctions de hachage est considérée comme fiable, ou pour se prémunir contre une éventuelle compromission des réseaux à l’avenir. Les autorités de certification et les systèmes gouvernementaux qui signent rarement mais exigent un niveau d’assurance maximal pourraient privilégier SLH-DSA, tandis que les serveurs TLS qui signent fréquemment préféreraient ML-DSA.

FN-DSA (FIPS 206, fondé sur FALCON) offre des signatures plus courtes que ML-DSA (897 octets pour FALCON-512 avec une sécurité de 128 bits), en utilisant des réseaux NTRU et un échantillonnage gaussien. Toutefois, FALCON exige une implémentation soigneusement réalisée en temps constant pour éviter les attaques par canal auxiliaire dues à l’échantillonneur gaussien. FIPS 206 devrait être normalisé après FIPS 203 à 205 et fournira une option hautes performances pour les environnements aux ressources limitées.

Quel est le principal avantage de SLH-DSA en matière de sécurité par rapport à ML-DSA ?

ML-DSA (FIPS 204) utilise Fiat-Shamir avec rejets sur Module-LWE, offrant une signature rapide avec des signatures de 3 KB (pour une sécurité de 192 bits). SLH-DSA (FIPS 205) utilise des arbres de Merkle fondés sur le hachage (WOTS+) et repose uniquement sur la sécurité des fonctions de hachage, avec des signatures de 7 à 50 KB. ML-DSA est privilégié pour les applications sensibles aux performances ; SLH-DSA, pour une prudence maximale. FN-DSA (FALCON, FIPS 206) ajoutera une option fondée sur des réseaux et produisant des signatures plus courtes.