FN-DSA vs ML-DSA compare les deux schémas de signature fondés sur les réseaux euclidiens que le NIST a sélectionnés en 2022. ML-DSA (issu de CRYSTALS-Dilithium) est devenu FIPS 204 en août 2024. FN-DSA, le nom que le NIST donne à Falcon, est en cours de normalisation sous le nom FIPS 206, qui n’était encore qu’un projet en octobre 2026. Falcon est bien plus compact ; ML-DSA est bien plus facile à implémenter correctement.
Vue d’ensemble
| FN-DSA-512 (Falcon-512) | ML-DSA-44 | FN-DSA-1024 (Falcon-1024) | ML-DSA-87 | |
|---|---|---|---|---|
| Catégorie de sécurité | 1 | 2 | 5 | 5 |
| Clé publique | 897 octets | 1312 octets | 1793 octets | 2592 octets |
| Signature | 666 octets (avec remplissage) | 2420 octets | 1280 octets (avec remplissage) | 4627 octets |
| Clé publique + signature | 1563 octets | 3732 octets | 3073 octets | 7219 octets |
| Famille de réseaux | NTRU | Module-LWE / Module-SIS | NTRU | Module-LWE / Module-SIS |
| Arithmétique de signature | Virgule flottante (échantillonnage gaussien discret) | Entiers uniquement | Virgule flottante | Entiers uniquement |
| Norme | Projet de FIPS 206 | FIPS 204 (finale, 2024) | Projet de FIPS 206 | FIPS 204 |
| X.509 | Pas encore normalisé | RFC 9881 | Pas encore normalisé | RFC 9881 |
Tailles de Falcon tirées de la spécification Falcon (les signatures peuvent aussi utiliser un encodage compressé de longueur variable, d’au plus 752 et 1462 octets) ; tailles de ML-DSA tirées du tableau 2 de FIPS 204. ML-DSA-65 (catégorie 3) n’a pas d’équivalent Falcon.
Pourquoi la taille compte
Falcon produit un vecteur court dans un réseau NTRU à l’aide d’une trappe et d’un échantillonnage de Fourier rapide (fast Fourier sampling), ce qui donne la plus petite taille cumulée de clé publique et de signature parmi toutes les signatures post-quantiques du NIST : environ 1,6 Ko en catégorie 1, contre 3,7 Ko pour ML-DSA-44. Dans une chaîne de certificats TLS, où chaque certificat porte une clé publique et une signature et où le handshake ajoute d’autres signatures et des SCT, cette différence sépare une chaîne dont la taille double à peu près d’une chaîne dont la taille quadruple. DNSSEC, où les signatures doivent tenir dans des réponses UDP, et les blockchains, où chaque octet se paie en frais, la ressentent encore davantage.
Pourquoi l’implémentation est le point difficile
L’algorithme de signature de Falcon échantillonne selon une distribution gaussienne discrète sur le réseau, en arithmétique à virgule flottante. Cela crée trois problèmes que ML-DSA n’a pas :
- Temps constant. Sur certains processeurs, la durée des opérations en virgule flottante peut dépendre des données, et les émuler avec des entiers est lent ; des attaques issues de la recherche ont montré que des fuites temporelles dans l’échantillonneur révèlent les clés.
- Testabilité. À cause des arrondis, deux implémentations correctes peuvent produire des signatures différentes pour la même entrée ; les tests à réponse connue ne peuvent donc pas détecter un échantillonneur subtilement biaisé, et un échantillonneur biaisé produit toujours des signatures valides tout en laissant fuir des informations sur la clé. En septembre 2026, l’équipe FIPS 206 du NIST a proposé une procédure de signature en virgule fixe, précisément pour que les implémentations deviennent déterministes et testables.
- Portabilité. Les processeurs embarqués dépourvus d’unité de calcul en virgule flottante ont besoin d’une émulation logicielle, qui coûte en vitesse et en taille de code.
ML-DSA n’utilise que de l’arithmétique entière modulo 8 380 417, avec échantillonnage par rejet ; il est simple de le rendre en temps constant, et ses sorties sont entièrement spécifiées par FIPS 204. La vérification est facile pour les deux, et Falcon vérifie particulièrement vite : l’implémentation de référence de l’équipe Falcon annonce environ 27 900 vérifications Falcon-512 et 5900 signatures par seconde sur un Intel Core i5-8259U à 2,3 GHz. Sur un cœur d’Apple M4 Max, le code ML-DSA-44 portable d’OpenSSL 3.6.5 a atteint environ 20 800 vérifications et 3900 signatures par seconde. Les machines diffèrent : lisez donc ces chiffres comme des ordres de grandeur, pas comme une comparaison directe.
État de la normalisation
- ML-DSA : norme finale depuis le 13 août 2024 (FIPS 204), avec des identifiants X.509 (RFC 9881), des profils CMS et OpenPGP, une sélection dans CNSA 2.0 (ML-DSA-87) et des modules validés.
- FN-DSA : le NIST a annoncé en juillet 2022 qu’il normaliserait Falcon et a prévu FIPS 206 après FIPS 204 et 205. Des représentants du NIST ont indiqué en 2025 que le projet public initial était pour l’essentiel rédigé et en attente d’approbation ; en octobre 2026, aucune norme finale n’existe, et la proposition en virgule fixe de septembre 2026 montre que la spécification évolue encore. Les Internet-Drafts de l’IETF consacrés à FN-DSA dans JOSE, COSE et X.509 suivent l’évolution de la norme FIPS.
Comme FIPS 206 peut différer de la spécification Falcon du 3e tour, les implémentations écrites aujourd’hui peuvent nécessiter des modifications pour se conformer à la norme finale.
Quand choisir l’un ou l’autre
- Signature post-quantique à usage général, aujourd’hui : ML-DSA (44 ou 65).
- Déploiements soumis à des exigences de conformité (FIPS 140-3, CNSA 2.0) : ML-DSA ; FN-DSA ne peut pas être validé avant la version finale de FIPS 206.
- Protocoles riches en certificats, à l’avenir (chaînes TLS, DNSSEC, mises à jour d’appareils IoT contraints) : suivez FN-DSA ; c’est le moyen le plus probable de garder le surcoût des signatures maîtrisable sans changer la structure du protocole.
- Matériel sans virgule flottante ou soumis à des exigences strictes face aux canaux auxiliaires : ML-DSA, ou Falcon uniquement avec une implémentation entière en temps constant éprouvée.
- Racines à longue durée de vie, où la taille importe peu : SLH-DSA, dont la sécurité repose uniquement sur des fonctions de hachage, ou ML-DSA ; les petites signatures de FN-DSA n’y apportent rien.
Notes de migration
- Concevez pour l’agilité algorithmique : incluez des identifiants d’algorithme, évitez les tailles de signature fixes et préparez-vous à ajouter FN-DSA comme seconde option post-quantique à côté de ML-DSA.
- Prototypez avec prudence : utilisez des bibliothèques qui implémentent l’échantillonneur de Falcon en temps constant et marquez leurs sorties comme antérieures à la norme ; ne les livrez pas là où une norme est exigée.
- Mesurez le budget de taille de votre protocole avec ML-DSA dès aujourd’hui ; si ML-DSA tient dans ce budget, vous n’aurez peut-être jamais besoin de FN-DSA à cet endroit.
- Surveillez la version finale de FIPS 206 : les noms des paramètres, les encodages et la procédure de signature peuvent différer de ceux de Falcon du 3e tour, et les vecteurs de test changeront en conséquence.
- Pensez aux hybrides : pendant la transition, les signatures composites associent un schéma post-quantique à ECDSA ou EdDSA, quel que soit le schéma fondé sur les réseaux que vous choisissez.