Comment le Bitcoin résiste-t-il aux ordinateurs quantiques ? Comparaison des avantages et inconvénients de trois schémas de signature basés sur les réseaux de codes

Rédigé par : Blockstream Team

Traduit par : Saoirse, Foresight News

*Le Blockstream Research Institute a publié un rapport de recherche complet sur les signatures basées sur les réseaux de codes pour Bitcoin. Cet article résume le contenu de la recherche, les principales conclusions et les recommandations associées, * le rapport complet peut être consulté ici .

Les signatures numériques sont le mécanisme central d'autorisation des transactions Bitcoin, et les signatures Schnorr et ECDSA qui remplissent cette fonction ont un coût très faible aujourd'hui. En 1994, Shor a prouvé qu'un ordinateur quantique suffisamment puissant pourrait casser ces deux types de signatures. Bien qu'il y ait encore un large débat sur le moment où de telles machines pourraient voir le jour, nous devons établir un plan de déploiement de signatures post-quantique viable avant que le problème ne se pose réellement.

Les schémas de signature basés sur les réseaux de codes sont des candidats populaires pour remplacer les signatures existantes. La cryptographie basée sur les réseaux de codes a plus d'un siècle de recherche derrière elle, et ses applications cryptographiques se sont développées depuis près de trente ans. Dans le cadre des systèmes cryptographiques post-quantiques, les signatures basées sur les réseaux de codes présentent de nombreux avantages : la taille totale de la clé publique et de la signature peut être inférieure à 1,6 Ko, et leur structure algébrique a le potentiel de soutenir des signatures multi-signatures, des signatures à seuil et des preuves succinctes à l'avenir.

Ce rapport examine trois schémas : Dilithium, Falcon et Hawk. Pour les lecteurs qui ne connaissent pas la cryptographie basée sur les réseaux de codes, nous expliquons les concepts de conception de chaque schéma, présentons le processus algorithmique complet et analysons les dimensions de sécurité, de performance et de déploiement pratique (par exemple, la dérivation de clés de portefeuille). Parmi ces trois schémas, lesquels peuvent réellement être déployés sur la chaîne Bitcoin ?

Dimensions d'évaluation

Le choix des schémas de signature pour Bitcoin est soumis à des contraintes spécifiques, et cette évaluation repose sur quatre critères clés :

• Coût en chaîne : L'un des indicateurs les plus importants est la taille totale de la clé publique et de la signature. Lorsque la sortie est dépensée, la clé publique et la signature sont enregistrées sur la chaîne, et chaque nœud complet doit 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, et une vitesse de vérification lente peut alourdir l'ensemble du réseau.
• Complexité de mise en œuvre : La capacité à mettre en œuvre le schéma de manière sécurisée est essentielle. Si la conception nécessite des calculs à virgule flottante ou un échantillonnage gaussien précis, une erreur d'implémentation ou une attaque par canaux latéraux comme l'analyse temporelle pourrait compromettre la clé. Pour une migration en douceur, la complexité de mise en œuvre est un facteur à ne pas négliger.
• Risques de déploiement : L'intégration réelle de Bitcoin rencontrera également divers obstacles pratiques : le choix de la fonction de hachage au niveau du consensus (la plupart des candidats utilisent SHAKE, tandis que Bitcoin utilise SHA-256), la reproductibilité des résultats de signature sur différentes plateformes, et si le programme de signature est compatible avec les limitations de mémoire des portefeuilles matériels.
• Potentiel de développement : La grande majorité des portefeuilles Bitcoin utilisent le mécanisme de déterminisme hiérarchique BIP-32 : à partir d'une seule clé publique principale, il est possible de dériver un nombre infini de sous-clés publiques sans accéder à la clé privée. Actuellement, les schémas de signature post-quantique standardisés ne prennent pas en charge cette fonctionnalité nativement, c'est pourquoi nous étudions le coût de l'ajout de cette capacité ; nous examinons également diverses variantes non standard qui pourraient offrir des avantages supplémentaires.

Quel niveau de sécurité choisir ?

Avant de comparer les tailles, il est nécessaire de déterminer le niveau de sécurité cible, et ce choix n'est pas aussi simple qu'il 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 la taille des clés et des signatures augmente également.

Nous pensons que Bitcoin devrait adopter au moins le niveau de sécurité 3. Les sorties Bitcoin peuvent ne pas être dépensées pendant des décennies, et si les techniques d'analyse cryptographique avancent et que le niveau de sécurité réel du schéma diminue, les actifs seront verrouillés par des clés affaiblies, exposés à des risques à long terme. La cryptographie basée sur les réseaux de codes a déjà été soumise à près de trente ans d'analyse cryptographique publique, et la recherche sur l'adoption des courbes elliptiques par Bitcoin remonte encore plus loin. Cependant, la structure algébrique complexe des réseaux de codes présente encore de nombreuses failles exploitables pour de futures attaques, et nous ne devrions pas parier toute notre sécurité future sur cela.

Les principaux produits ont également fait le même constat. Le protocole PQ3 d'Apple pour iMessage abandonne directement les paramètres de réseau de codes de niveau 1, utilisant uniquement des paramètres de niveau 3 et 5 ; Cloudflare utilise ML-KEM-768 (niveau 3) dans son déploiement TLS post-quantique, indiquant que bien que le niveau 1 semble sûr pour le moment, il est nécessaire de prévoir une marge de sécurité pour les décennies à venir en matière d'analyse cryptographique. La période de sécurité de Bitcoin est encore plus longue que celles des deux exemples précédents.

Augmenter le niveau de sécurité a un coût. Par exemple, passer de Dilithium de niveau 2 à niveau 3 augmente la taille totale d'environ 1,5 Ko. Le rapport compare tous les ensembles de paramètres à différents niveaux de sécurité, permettant aux lecteurs de faire leurs propres choix. Le cas de Hawk prouve que des considérations de sécurité prudentes ne sont pas que des théories.

Détails des candidats

Dilithium : un schéma au design simple

Dilithium a été normalisé par le NIST en tant que ML-DSA dans la norme FIPS 204, transférant le paradigme d'engagement-défi-réponse des signatures Schnorr à l'arithmétique des réseaux de codes modulaires.

Sa principale caractéristique est sa simplicité. Tous les calculs de Dilithium sont des opérations entières : opérations sur des anneaux, multiplication de matrices et vecteurs, hachage, arrondi, sans opérations à virgule flottante ni échantillonnage gaussien discret. Cela facilite l'écriture d'implémentations sécurisées et à temps constant. C'est également le candidat le plus largement intégré, ayant été intégré dans OpenSSL, BoringSSL, AWS-LC et Apple CryptoKit.

Le coût est une taille relativement grande. Pour un niveau de sécurité 3, le ML-DSA-65 a une clé publique de 1952 octets et une signature de 3309 octets, soit un total de 5261 octets, environ 55 fois la taille totale de la clé publique/privée et de la signature d'origine de Bitcoin, ce qui en fait le plus grand des trois schémas à ce niveau de sécurité.

Pour Bitcoin, le plus précieux de Dilithium est qu'il est le seul des trois à se rapprocher d'une dérivation de clé de style BIP-32. La construction de clé de DilithiumRK peut générer des sous-clés à partir de la clé parente uniquement à partir d'informations publiques. Le rapport analyse trois variantes, dont DilithiumRKS que nous proposons, dont la logique de dérivation est entièrement intégrée dans le logiciel de portefeuille, et sur la chaîne, seul un vérificateur standard doit traiter les signatures ML-DSA ordinaires. Cependant, aucune des trois variantes n'a encore atteint les normes de mise en ligne : deux d'entre elles nécessitent des modifications du vérificateur, et DilithiumRKS lui-même manque d'une preuve complète d'irrévocabilité ; toutes les solutions dépendent d'une matrice partagée par l'ensemble du réseau, qui, bien que formellement sécurisée sous l'hypothèse Module-LWE, lie la sécurité de toutes les clés à la même instance. Nous pensons qu'à ce stade, la dérivation de clés publiques basée sur Dilithium n'est qu'une preuve de concept et ne peut pas être déployée dans la pratique.

Falcon : un schéma compact

Falcon a été sélectionné par le NIST, son nom normalisé étant FN-DSA, et c'est le plus épuré des trois. La clé publique et la signature de Falcon-512 de niveau 1 totalisent 1563 octets ; pour le niveau 5, Falcon-1024 totalise 3073 octets. Le Falcon-1024, qui offre une marge de sécurité plus élevée, est même plus petit que le Dilithium de niveau 3.

Falcon adopte une approche différente de Dilithium : un modèle de hachage-signature basé sur les réseaux de codes NTRU. La clé privée du signataire est un ensemble de bases courtes du réseau ; le message est haché et mappé à un point dans l'espace, et le signataire utilise cette base courte pour trouver un vecteur très proche de ce point dans le réseau. Ce point et ce vecteur voisin forment la signature ; la vérification consiste simplement à vérifier que le vecteur appartient au réseau et qu'il est suffisamment proche. La difficulté d'implémentation réside dans le fait de trouver le vecteur sans divulguer d'informations sur la base. Les premiers schémas GGH et NTRUSign prenaient directement des points proches du réseau, ce qui révélait une partie des informations géométriques à chaque signature. Falcon utilise le cadre GPV pour échantillonner des vecteurs voisins à partir d'une distribution gaussienne, prouvant que la sortie d'échantillonnage est indépendante de la base, éliminant ainsi le risque de fuite, mais cela augmente considérablement la difficulté d'implémentation de l'échantillonneur.

L'échantillonneur est le point faible de Falcon au niveau de l'ingénierie. Il nécessite des calculs à virgule flottante dans le domaine de Fourier complexe. Différents processeurs, compilateurs et options d'optimisation de compilation peuvent entraîner des résultats d'échantillonnage à virgule flottante incohérents. Ce n'est pas seulement un problème de compatibilité, mais aussi un risque de sécurité : la preuve de sécurité GPV exige qu'un signataire ne produise jamais deux ensembles de vecteurs courts différents pour le même hachage ; si la signature devient déterministe, les différences d'arrondi à virgule flottante dues à la plateforme pourraient compromettre cette condition. Il existe une solution viable : le Falcon déterministe peut utiliser des entiers pour simuler les calculs à virgule flottante, produisant des signatures totalement cohérentes sur toutes les plateformes. Le coût est une diminution de la vitesse de signature d'environ 15 fois et une diminution de la vitesse de génération de clés d'environ 2 fois.

Il est important de noter que la vérification n'est pas affectée : la vérification de Falcon se fait entièrement par des opérations entières, avec des résultats déterministes, et c'est également le schéma avec la vitesse de vérification la plus rapide. Cette caractéristique asymétrique est très favorable pour Bitcoin : la signature est effectuée une fois par le portefeuille lors de la dépense de la transaction, tandis que chaque signature doit être vérifiée par tous les nœuds du réseau. Une signature 15 fois plus lente est un coût faible, permettant d'obtenir une reproductibilité inter-plateformes et des opérations entières, ce qui, à notre avis, est un compromis raisonnable. Ainsi, le problème des calculs à virgule flottante peut être résolu par des moyens d'ingénierie, et n'est pas un défaut fatal.

Deux points à noter : en raison de contraintes structurelles, Falcon n'a pas de paramètres de niveau 3, et ne peut choisir que le niveau 1 ou le niveau 5. En tenant compte de la marge de sécurité, nous recommandons Falcon-1024. Deuxièmement, la signature consomme beaucoup de mémoire : l'échantillonneur du paramètre 1024 dépend d'un arbre de pré-calcul, occupant environ 90 Ko de mémoire. Les portefeuilles matériels peuvent reconstruire dynamiquement cet arbre par branche, réduisant l'utilisation de la mémoire à 16 Ko, mais le temps de signature sera doublé. Le ralentissement de la signature sur les appareils matériels est un coût réel, mais reste acceptable.

Hawk : un schéma déclaré défaillant

L'objectif de Hawk était de combiner les avantages des deux autres schémas : la signature Hawk-512 ne fait que 555 octets, plus petite que celle de Falcon ; toutes les opérations de signature sont des opérations entières, avec une utilisation mémoire minimale de seulement 6 Ko. C'est également le seul candidat basé sur les réseaux de codes qui a survécu au troisième tour du concours de signatures supplémentaires du NIST, et le rapport consacre une grande partie à ce schéma.

Le coût réside dans les hypothèses de sécurité. Il n'a pas utilisé les problèmes NTRU et SIS, qui ont été testés par des décennies d'analyse cryptographique, mais repose sur le problème d'isomorphisme de réseau et l'hypothèse one-more-SVP, qui ont une histoire de recherche relativement courte.

Juste avant la finalisation du rapport, Straznickas et Weis d'Anthropic ont découvert que la construction de réseau de Hawk présentait des défauts structurels : la récupération de la clé nécessitait en réalité de résoudre un problème SVP dont la dimension n'était que la moitié de celle envisagée par les concepteurs. La sécurité de récupération de la clé des ensembles de paramètres candidats a été considérablement affaiblie. Les chercheurs ont mené une attaque complète de récupération de clé de bout en bout sur les paramètres de défi HAWK-256 utilisés pour l'analyse cryptographique ; même après cette attaque, les propositions officielles HAWK-512 et HAWK-1024 ne pouvaient toujours pas être compromises dans la réalité. L'équipe de Hawk a confirmé l'efficacité de l'attaque et a retiré le schéma du processus NIST ; l'équipe a déclaré que si elle corrigeait la vulnérabilité en doublant les paramètres, l'avantage de taille dont Hawk était si fier disparaîtrait complètement.

Le rapport conserve néanmoins les sections concernant Hawk, car cette attaque cible les caractéristiques algébriques d'un domaine numérique spécifique, et ne remet pas en cause entièrement ce paradigme de conception. Il n'est pas encore certain qu'une nouvelle conception puisse éviter la vulnérabilité. L'incident Hawk illustre également de manière intuitive notre raison de maintenir une marge de sécurité prudente : même un schéma ayant une taille excellente, une vitesse impressionnante et ayant passé plusieurs cycles de normalisation peut voir son niveau de sécurité estimé considérablement diminuer par un seul article.

Tableau comparatif des schémas

Tous les schémas du tableau ci-dessus (y compris SPHINCS+) sont des signatures sans état : le signataire n'a pas besoin de conserver les signatures précédentes. Les signatures à hachage avec état comme XMSS peuvent produire des signatures plus petites, mais nécessitent de maintenir l'état de la signature ; vous pouvez consulter le * rapport thématique sur les signatures basées sur les hachages * pour plus de comparaisons.

De nombreux obstacles subsistent pour le déploiement

Falcon manque de schémas de dérivation de clés utilisables. Actuellement, le seul schéma de dérivation de style BIP-32 pour Falcon qui soit public nécessite une re-randomisation de la clé privée de base, ce qui augmente considérablement la limite supérieure de la norme de signature, faisant gonfler la signature sur la chaîne à environ 23,7 Ko. De plus, les paramètres de ce schéma ne répondent pas à ses propres conditions de sécurité, et si ce problème est corrigé, la taille augmentera encore. Il n'existe actuellement aucune mise en œuvre de dérivation de clés publiques Falcon viable, ce qui constitue le problème le plus précieux à résoudre dans le rapport.

La norme Falcon n'est pas encore finalisée. Bien que le NIST ait sélectionné Falcon, le projet FN-DSA n'a pas encore été officiellement publié. Ce n'est qu'après la finalisation de la normalisation que des mises en œuvre auditées, des vecteurs de test et un soutien matériel seront disponibles. Un déploiement large peut réduire les risques et la complexité d'intégration au niveau du consensus de Bitcoin. Nous recommandons d'attendre la publication officielle de FN-DSA ; jusqu'à ce moment, Falcon reste en état de changement.

La variante Falcon-WS : cette variante assouplit les paramètres internes, s'appuyant sur le rejet d'échantillonnage pour compenser, compressant la taille totale à 1114 octets pour le niveau 1 et à 2387 octets pour le niveau 5, réduisant encore la taille par rapport à la version originale de Falcon. Cette direction a une valeur de recherche, mais ne sera pas incluse dans la norme officielle, nécessitant plus de vérifications d'analyse cryptographique. Des recherches antérieures ont révélé des failles dans la preuve d'irrévocabilité forte de ses schémas dérivés (l'irrévocabilité ordinaire n'est pas affectée).

Des schémas meilleurs émergeront-ils à l'avenir ? En dehors des schémas mentionnés ci-dessus, la série Fiat-Shamir, qui remonte à BLISS en 2013, et les dernières avancées présentées par Gärtner lors de la conférence CRYPTO 2025, basées sur des hypothèses matures, peuvent rivaliser en taille avec Falcon. La difficulté d'implémentation de cette série réside dans les problèmes de sécurité d'implémentation : BLISS a été compromis par une attaque par canaux latéraux en raison d'un échantillonnage gaussien non constant ; les schémas ultérieurs n'ont pas complètement résolu cette vulnérabilité, et les dernières avancées indiquent que la protection lors de l'échantillonnage est encore plus difficile. Tant que ces problèmes ne sont pas résolus, ces schémas ne sont que théoriquement attrayants et ne conviennent pas au déploiement.

Les signatures basées sur les réseaux de codes et les signatures basées sur les hachages peuvent se compléter. Les signatures basées sur les réseaux de codes peuvent servir de composants dans des schémas hybrides. Par exemple, dans SHRINCS, le chemin de récupération sans état utilise actuellement des signatures SPHINCS+ de quelques Ko ; en les remplaçant par des signatures Falcon (ou Falcon-WS), la taille est plus petite, la vérification plus rapide, et les coûts de récupération à faible fréquence sont considérablement réduits, sans affecter le chemin d'utilisation quotidien.

Conclusions de la recherche

Le classement des candidats basés sur les réseaux de codes est très clair : Hawk a été retiré de la compétition après avoir été attaqué par l'équipe d'Anthropic ; Dilithium a la difficulté d'implémentation la plus faible et est le seul à avoir une base de recherche sur la dérivation de clés, mais sa taille n'est pas favorable pour les coûts sur la chaîne Bitcoin ; Falcon combine une taille compacte, une vérification rapide et des hypothèses de sécurité matures ; son principal inconvénient - les calculs à virgule flottante lors de la signature - a déjà des solutions d'ingénierie viables. Si nous devions choisir un schéma de signature basé sur les réseaux de codes pour Bitcoin maintenant, nous choisirions Falcon-1024.

À l'heure actuelle, notre point de vue reste en accord avec le rapport sur les signatures basées sur les hachages : la voie conservatrice à court terme reste les signatures basées sur les hachages, dont les hypothèses de sécurité sont les plus matures, le risque le plus faible, et qui conviennent comme solution de transition. Une fois que FN-DSA sera officiellement finalisé, avec des normes stables, un code audité et un soutien matériel, Falcon apportera des améliorations significatives par rapport aux signatures basées uniquement sur les hachages ; il est également possible d'adopter un déploiement hybride, permettant aux deux systèmes de signature de se compléter.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.