Rédigé par : Blockstream Team
Compilé par : Saoirse, Foresight News
Blockstream Research a publié un rapport complet sur les signatures à base de réseaux pour Bitcoin. Cet article résume la recherche, les découvertes clés et les recommandations associées. Lerapport complet peut être consulté ici.
Les signatures numériques sont au cœur du mécanisme d'autorisation des transactions Bitcoin, actuellement assuré par les signatures Schnorr et ECDSA à très faible coût. En 1994, Shor a prouvé qu'un ordinateur quantique suffisamment puissant pourrait casser ces deux types de signatures. Bien que le moment où une telle machine pourrait voir le jour fasse toujours l'objet de nombreux débats, il est nécessaire d'élaborer une stratégie de déploiement de signatures post-quantiques avant que le problème ne se présente réellement.
Les schémas de signature à base de réseaux (lattices) sont des candidats populaires pour remplacer les signatures actuelles. La cryptographie basée sur les réseaux a été étudiée depuis plus d'un siècle, et ses applications cryptographiques se développent depuis près de trente ans. Dans le cadre de la cryptographie post-quantique, les signatures à base de réseaux présentent de nombreux avantages : la taille totale des clés publiques et des signatures peut être inférieure à 1,6 kilo-octet, et leur structure algébrique pourrait à l'avenir permettre des signatures multiples, des signatures à seuil et des preuves succinctes.
Ce rapport étudie trois schémas : Dilithium, Falcon et Hawk. Pour les lecteurs peu familiers avec la cryptographie basée sur les réseaux, nous expliquons la philosophie de conception de chaque schéma, décrivons complètement leurs processus algorithmiques, et analysons leurs dimensions de sécurité, de performance et de déploiement pratique (par exemple, la dérivation des clés de portefeuille). Parmi ces trois, quels schémas pourraient réellement être déployés sur la blockchain Bitcoin ?
Dimensions d'évaluation
Le choix d'un schéma de signature pour Bitcoin est soumis à ses propres contraintes. Cette évaluation s'articule autour de quatre critères essentiels :
- Coût sur la chaîne : L'un des indicateurs les plus importants est la taille totale de la clé publique et de la signature. Lorsqu'une sortie (output) est dépensée, la clé publique et la signature sont toutes deux enregistrées sur la chaîne, et les nœuds complets doivent télécharger et stocker chaque octet. Le coût de vérification est également crucial : chaque signature doit être vérifiée par tous les nœuds du réseau, une vérification lente imposant une charge à l'ensemble du réseau.
- Complexité de mise en œuvre : La possibilité d'une implémentation sécurisée du schéma est primordiale. Si la conception nécessite des calculs en virgule flottante ou un échantillonnage gaussien précis, une erreur d'implémentation ou une attaque par canal auxiliaire comme l'analyse temporelle pourrait divulguer la clé secrète. Pour assurer une migration en douceur, la complexité de mise en œuvre est un facteur à ne pas négliger.
- Risques de déploiement : L'intégration pratique dans Bitcoin rencontre divers obstacles réels : le choix de la fonction de hachage au niveau du consensus (la plupart des schémas candidats utilisent SHAKE, tandis que Bitcoin utilise SHA‐256), la reproductibilité des résultats de signature sur différentes plateformes, et l'adaptation de la procédure de signature aux limitations mémoire des portefeuilles matériels.
- Potentiel d'évolution : La grande majorité des portefeuilles Bitcoin utilisent le mécanisme hiérarchique déterministe BIP‐32 : à partir d'une seule clé publique maîtresse, il est possible de dériver une infinité de clés publiques enfants sans toucher à la clé privée. Actuellement, aucun schéma de signature post-quantique standardisé ne prend en charge nativement cette fonctionnalité. Nous étudions donc le coût de son ajout ; nous examinons également diverses variantes non standardisées, qui pourraient offrir des avantages supplémentaires.
Quel niveau de sécurité choisir ?
Avant de comparer les tailles, il faut déterminer le niveau de sécurité cible, un choix moins simple qu'il n'y paraît. Le NIST classe les niveaux de sécurité de 1 à 5 ; plus le niveau est élevé, plus la sécurité est forte, mais plus le volume des clés et des signatures est important.
Nous pensons que Bitcoin devrait au minimum adopter un niveau de sécurité 3. Une sortie Bitcoin peut ne pas être dépensée pendant des décennies. Si les progrès en cryptanalyse réduisent le niveau de sécurité réel du schéma, les actifs seront verrouillés par des clés affaiblies, exposés à long terme au risque. Les hypothèses cryptographiques des réseaux ont été soumises à près de trente ans de cryptanalyse publique, une période plus longue que celle de la courbe elliptique lors de son adoption par Bitcoin. Cependant, la structure algébrique complexe des réseaux laisse encore de nombreuses ouvertures potentielles pour de futures attaques. Nous ne devrions pas parier toute notre sécurité future lointaine sur celle-ci.
Les principaux acteurs ont fait le même constat. Le protocole PQ3 d'iMessage d'Apple abandonne directement les paramètres de niveau 1 pour les réseaux, utilisant exclusivement des paramètres de niveaux 3 et 5 ; Cloudflare utilise ML‐KEM‐768 (niveau 3) dans son déploiement TLS post-quantique, indiquant que si le niveau 1 semble sûr actuellement, il faut prévoir une marge de sécurité pour les décennies futures de cryptanalyse. L'horizon temporel de sécurité de Bitcoin est encore plus long que ces deux exemples.
Augmenter le niveau de sécurité a un coût. Par exemple, passer de Dilithium niveau 2 à niveau 3 augmente la taille totale d'environ 1,5 kilo-octet. Le rapport compare les ensembles de paramètres pour tous les niveaux de sécurité, permettant au lecteur de faire son propre arbitrage. Le cas de Hawk prouve que des considérations de sécurité conservatrices ne sont pas qu'un exercice théorique.
Détail des schémas candidats
Dilithium : Un schéma à la conception simple
Dilithium a été standardisé par le NIST sous le nom ML‐DSA dans la norme FIPS 204. Il transpose le paradigme engagement-défi-réponse de la signature Schnorr à l'arithmétique des réseaux modulaires.
Sa principale caractéristique est sa simplicité. Tous les calculs de Dilithium sont des opérations sur des entiers : opérations d'anneau, multiplications matrice-vecteur, hachage, arrondi. Il n'y a pas d'opérations en virgule flottante, ni besoin d'échantillonnage gaussien discret. Il est plus facile d'écrire une implémentation sécurisée et à temps constant. C'est aussi le candidat le plus largement déployé, intégré dans OpenSSL, BoringSSL, AWS‐LC et Apple CryptoKit.
Le prix à payer est un volume relativement important. ML‐DSA‐65 (niveau 3) a une clé publique de 1952 octets, une signature de 3309 octets, totalisant 5261 octets, soit environ 55 fois la taille totale des clés publiques/privées natives de Bitcoin plus la signature. C'est le plus volumineux des trois schémas à niveau de sécurité équivalent.
Le point le plus précieux de Dilithium pour Bitcoin : c'est le seul des trois à s'approcher d'une implémentation de dérivation de clés de style BIP‐32. La construction DilithiumRK avec clé rerandomisable permet de générer des clés enfants à partir d'une clé parente en utilisant uniquement des informations publiques. Le rapport analyse trois variantes, dont notre proposition DilithiumRKS, où la logique de dérivation est entièrement gérée par le logiciel du portefeuille, la chaîne ne nécessitant qu'un vérificateur standard traitant des signatures ML‐DSA ordinaires. Cependant, aucune n'est encore prête pour le déploiement : deux variantes nécessitent de modifier le vérificateur, DilithiumRKS lui-même manque encore d'une preuve complète d'inaltérabilité (unforgeability) ; tous les schémas dépendent d'une matrice commune à tout le réseau, ce qui, bien que formellement sûr sous l'hypothèse Module‐LWE, lie la sécurité de toutes les clés à une même instance. Nous considérons que la dérivation de clés publiques basée sur Dilithium n'est actuellement qu'une preuve de concept, inapte à un déploiement réel.
Falcon : Un schéma compact
Falcon a été sélectionné par le NIST, son nom standardisé est FN‐DSA. C'est le plus compact des trois. Falcon‐512 (niveau 1) totalise 1563 octets pour la clé publique plus la signature ; Falcon‐1024 (niveau 5) totalise 3073 octets. Falcon‐1024, avec une marge de sécurité plus élevée, est même plus petit que Dilithium niveau 3.
Falcon adopte une approche différente de Dilithium : un schéma de signature à hachage (hash-and-sign) basé sur les réseaux NTRU. La clé privée du signataire est une base courte du réseau ; le message est haché en un point de l'espace, le signataire utilise la base courte pour trouver un vecteur du réseau proche de ce point. Le point et ce vecteur proche constituent ensemble la signature ; la vérification contrôle seulement que le vecteur appartient au réseau et est suffisamment proche. La difficulté de mise en œuvre réside dans la recherche du vecteur sans divulguer d'information sur la base. Les premiers schémas GGH, NTRUSign prenaient directement le point du réseau le plus proche, chaque signature divulguant une partie de l'information géométrique. Falcon utilise le cadre GPV, échantillonnant le vecteur proche à partir d'une distribution gaussienne, prouvant que la sortie de l'échantillonnage est indépendante de la base, éliminant le risque de fuite, mais augmentant considérablement la difficulté de mise en œuvre de l'échantillonneur.
L'échantillonneur est le point faible technique de Falcon. Il opère dans le domaine de Fourier complexe, nécessitant des calculs en virgule flottante. Différents processeurs, compilateurs, options de compilation/optimisation peuvent conduire à des résultats de sortie en virgule flottante non identiques. Ce n'est pas seulement un problème de compatibilité, mais aussi de sécurité : la preuve de sécurité GPV exige que pour un même digest, le signataire ne produise jamais deux vecteurs courts différents ; une fois la signature rendue déterministe, les différences d'arrondi des virgules flottantes dues à la plateforme brisent cette condition. Des solutions existent : un Falcon déterministe peut simuler des entiers à la place des virgules flottantes matérielles, produisant des signatures parfaitement identiques sur toutes les plateformes. Le coût est une baisse de vitesse de signature d'environ 15 fois et de génération de clés d'environ 2 fois.
Important : l'étape de vérification n'est pas affectée : la vérification de Falcon utilise exclusivement des opérations sur entiers, est déterministe, et est aussi la plus rapide parmi les candidats. Cette asymétrie est très favorable à Bitcoin : la signature est exécutée une fois par le portefeuille lors de la création de la transaction de dépense, tandis que chaque signature doit être vérifiée par tous les nœuds complets du réseau. Un ralentissement d'un facteur 15 pour la signature est une dépense peu fréquente, un compromis raisonnable à nos yeux pour obtenir une reproductibilité multiplateforme et des opérations sur entiers. Ainsi, le problème des virgules flottantes est un obstacle surmontable par des moyens techniques, pas une faille fatale.
Deux points à noter : en raison de contraintes structurelles, Falcon n'a pas de paramètres de niveau 3, le choix est entre niveau 1 ou 5. Pour des raisons de marge de sécurité, nous recommandons Falcon‐1024. Deuxièmement, la signature consomme beaucoup de mémoire : l'échantillonneur pour l'ensemble de paramètres 1024 dépend d'un arbre pré-calculé, occupant environ 90 kilo-octets. Les portefeuilles matériels peuvent reconstruire dynamiquement cet arbre branche par branche, réduisant l'empreinte mémoire à environ 16 kilo-octets, mais doublant le temps de signature. Ralentir la signature sur les appareils matériels est un coût réel, mais acceptable.
Hawk : Un schéma ayant échoué
L'objectif de Hawk était de fusionner les avantages des deux autres schémas : Hawk‐512 a une signature de seulement 555 octets, plus petite que Falcon ; le côté signature utilise exclusivement des opérations sur entiers, avec une empreinte mémoire minimale de seulement 6 kilo-octets. C'était aussi le seul candidat à base de réseaux restant au troisième tour du concours de signatures supplémentaires du NIST, le rapport lui consacre de nombreuses pages.
Le coût réside dans ses hypothèses de sécurité. Il ne repose pas sur les problèmes NTRU ou SIS, éprouvés par des décennies de cryptanalyse, mais sur le problème d'isomorphisme de réseaux et l'hypothèse one‐more‐SVP, deux hypothèses ayant une histoire de recherche relativement plus courte.
Juste avant la finalisation du rapport, Straznickas et Weis d'Anthropic ont découvert une faille structurelle dans la construction du réseau de Hawk : la dimension du problème SVP à résoudre réellement pour récupérer la clé n'est que la moitié de celle envisagée par les concepteurs. Le niveau de sécurité estimé pour la récupération de clé des paramètres candidats a été considérablement réduit. Les chercheurs ont mené une attaque complète de bout en bout de récupération de clé sur les paramètres de défi HAWK‐256 utilisés pour la cryptanalyse ; même attaqués, les propositions formelles HAWK‐512 et HAWK‐1024 ne peuvent toujours pas être cassées en pratique. L'équipe Hawk a confirmé l'efficacité de l'attaque et a retiré le schéma du processus du NIST ; l'équipe a indiqué que si le défaut était corrigé en doublant les paramètres, l'avantage de taille dont Hawk était si fier disparaîtrait complètement.
Le rapport conserve néanmoins les chapitres sur Hawk, car cette attaque cible des propriétés algébriques spécifiques à un corps de nombres, et ne rejette pas entièrement ce paradigme de conception. On ne sait pas encore si une nouvelle conception pourrait éviter la faille. L'incident Hawk illustre également clairement notre raison de maintenir une marge de sécurité conservatrice : un schéma, même excellent en taille et vitesse, et ayant passé plusieurs tours de standardisation, peut voir son niveau de sécurité estimé chuter considérablement suite à un seul article.
Tableau comparatif des schémas
Tous les schémas du tableau ci-dessus (y compris SPHINCS+) sont des signatures sans état (stateless) : le signataire n'a pas besoin de conserver un historique des signatures. Les signatures à hachage avec état (stateful) comme XMSS peuvent avoir des signatures encore plus petites, mais nécessitent de maintenir un état de signature ; consultez lerapport spécial sur les signatures à base de hachagepour une comparaison.
Des obstacles subsistent pour le déploiement
Falcon manque d'un schéma de dérivation de clés utilisable. Actuellement, la seule proposition publique de dérivation de style BIP‐32 pour Falcon rerandomise la base de la clé privée, ce qui augmente considérablement la norme maximale des signatures, faisant gonfler la signature sur la chaîne à environ 23,7 kilo-octets. De plus, les paramètres de cette proposition ne satisfont pas ses propres conditions de sécurité ; si ce problème était corrigé, le volume augmenterait encore plus. Il n'existe actuellement aucune implémentation viable de dérivation de clés publiques pour Falcon, ce qui est aussi le problème ouvert le plus précieux identifié par le rapport.
La norme Falcon n'est pas encore finalisée. Bien que le NIST ait sélectionné Falcon, le projet de norme FN‐DSA n'est pas encore officiellement publié. Une fois la standardisation terminée, elle apportera des implémentations auditées, des vecteurs de test et un support matériel. Un déploiement large réduirait les risques et difficultés d'intégration au niveau du consensus de Bitcoin. Nous recommandons d'attendre la publication officielle de FN‐DSA ; avant cela, Falcon reste dans un état de flux.
Variante Falcon‐WS : Cette variante assouplit les paramètres internes, compensant par un échantillonnage par rejet (rejection sampling), réduisant la taille totale à 1114 octets pour le niveau 1 et 2387 octets pour le niveau 5, soit une réduction supplémentaire par rapport à la version originale de Falcon. Cette direction a une valeur de recherche, mais ne fera pas partie de la norme officielle et nécessite davantage de validation cryptanalytique. Des recherches ont déjà trouvé une faille dans la preuve de forte inaltérabilité (strong unforgeability) d'un schéma dérivé (l'inaltérabilité ordinaire n'est pas affectée).
Un schéma plus performant apparaîtra-t-il à l'avenir ? Outre les schémas ci-dessus, la série Fiat‐Shamir remonte au BLISS de 2013 ; les derniers travaux de Gärtner présentés à CRYPTO 2025, basés sur des hypothèses matures, affichent sur le papier des tailles comparables à Falcon. La racine de la difficulté de déploiement technique de cette série est la sécurité de mise en œuvre : BLISS a été cassé par canal auxiliaire à cause d'un échantillonnage gaussien non constant dans le temps ; les schémas suivants n'ont pas complètement résolu cette faiblesse, et les derniers travaux indiquent également que la protection lors de l'échantillonnage est plus difficile. Tant que ce problème n'est pas résolu, ces schémas n'ont qu'un attrait théorique et ne conviennent pas au déploiement.
Les signatures à base de réseaux et à base de hachage peuvent être complémentaires. Les signatures à base de réseaux peuvent être un composant dans des schémas hybrides. Par exemple, dans SHRINCS, le chemin de récupération sans état utilise actuellement des signatures SPHINCS+ de plusieurs kilo-octets ; le remplacer par une signature Falcon (ou Falcon‐WS) offrirait un volume plus petit, une vérification plus rapide, réduisant considérablement le coût peu fréquent du chemin de récupération, sans affecter le chemin d'utilisation quotidienne.
Conclusion de la recherche
L'ordre de classement des avantages et inconvénients des candidats à base de réseaux est très clair : Hawk est hors course après l'attaque de l'équipe d'Anthropic ; Dilithium est le plus simple à implémenter et le seul ayant des bases de recherche sur la dérivation de clés, mais son volume est peu favorable au coût sur la chaîne Bitcoin ; Falcon combine un volume compact, une vérification rapide et des hypothèses de sécurité matures ; son principal défaut — les calculs en virgule flottante côté signature — possède déjà une solution technique viable. Si nous devions choisir dès maintenant un schéma de signature à base de réseaux pour Bitcoin, nous opterions pour Falcon‐1024.
Pour l'instant, notre point de vue rejoint celui du rapport sur les signatures à base de hachage : la voie conservatrice à court terme reste les signatures à base de hachage, leurs hypothèses de sécurité étant les plus matures, présentant le risque le plus faible, et convenant comme solution de transition. Une fois la norme FN‐DSA finalisée, avec des spécifications stables, des bibliothèques de code auditées et un support des portefeuilles matériels, Falcon apporterait une amélioration significative par rapport aux signatures purement à base de hachage ; un déploiement hybride pourrait également être adopté, laissant les deux systèmes de signature se compléter.
