Bitcoin ECDSA sous menace quantique : quelles signatures post-quantiques un développeur peut-il simuler ?

La sécurité de Bitcoin pour les dépenses repose sur ECDSA sur secp256k1, et ce système est compris comme étant cassable par l'algorithme de Shor exécuté sur un ordinateur quantique suffisamment grand [2]. Aucun ordinateur quantique pertinent pour la cryptographie (CRQC) n'existe aujourd'hui, et l'écart entre le matériel actuel et une telle machine est décrit comme grand [2]. Cela signifie que la menace n'est pas immédiate, mais les développeurs et les concepteurs de protocoles qui planifient des cycles de vie de logiciels ou de portefeuilles de plusieurs années ont besoin d'une estimation honnête de la marge disponible avant qu'une transition vers des signatures post-quantiques ne devienne urgente.

Les estimations de cette marge divergent. Un article déclare que le système de signature à courbe elliptique de Bitcoin pourrait être complètement cassé par un ordinateur quantique dès 2027 selon l'estimation la plus optimiste [7] ; ce chiffre est à nouveau mentionné dans les Sections 3 et 8 de cette note plutôt que répété en entier. Un autre article de cet ensemble insiste plutôt sur le fait qu'aucun CRQC n'existe et que la distance jusqu'à un est grande, sans s'engager sur une année [2]. Ce sont des cadrages différents provenant d'articles différents, l'un donnant une date optimiste et l'autre soulignant l'impossibilité actuelle, et un développeur devrait considérer 2027 comme une limite inférieure dans des hypothèses favorables plutôt qu'une prévision consensuelle.

Les deux moitiés de la sécurité de Bitcoin, les signatures et la preuve de travail, ne sont pas exposées de manière égale. L'algorithme de Shor menace les systèmes de signature ECDSA sur secp256k1 et BLS sur BLS12-381 [2], mais la même catégorie d'attaque ne s'applique pas au minage. La preuve de travail est décrite comme relativement résistante à une accélération quantique substantielle au cours des 10 prochaines années [7], et l'algorithme de Grover, la méthode quantique qui s'applique en principe aux problèmes de type recherche comme la preuve de travail, ne la menace pas de manière significative car son accélération n'est que quadratique, car elle est sapée par le coût par opération tolérant aux fautes et par un mur de parallélisation K√K, et car l'ajustement de la difficulté de Bitcoin annule l'accélération [2].

Parce que les signatures et le minage font face à des profils de risque si différents, la priorité pratique de l'ingénierie est claire : travailler sur le remplacement des signatures post-quantiques, pas sur le minage post-quantique. Cela façonne le reste de cette note, qui se concentre sur ce qu'un développeur peut construire et mesurer aujourd'hui avec des systèmes de signature post-quantiques dans un environnement Bitcoin simulé.

Deux menaces algorithmiques distinctes sont discutées dans la littérature examinée ici, et elles ne doivent pas être confondues. L'algorithme de Shor est celui qui importe pour les signatures de Bitcoin : il peut casser ECDSA sur secp256k1 et BLS sur BLS12-381 [2]. Les ordinateurs quantiques sont, plus généralement, théoriquement capables de casser les hypothèses de dureté computationnelle sous-jacentes pour de nombreux systèmes cryptographiques existants [13]. L'utilisation de l'ECDSA par Bitcoin est spécifiquement signalée comme n'étant pas sécurisée post-quantique à cause de l'algorithme de Shor [12].

L'algorithme de Grover est l'autre algorithme quantique couramment discuté, mais il cible une partie différente du système : le minage, pas la signature. Il ne menace pas significativement la preuve de travail de Bitcoin, car son accélération n'est que quadratique, il est écrasé par le coût par opération tolérant aux fautes et un mur de parallélisation K√K, et l'ajustement de la difficulté annule l'accélération [2]. L'affirmation vérifiée liste le coût par opération tolérant aux fautes comme l'un des facteurs écrasants sans élaborer davantage sur le mécanisme, donc aucun détail supplémentaire sur pourquoi ce coût est plus lent qu'une puce classique n'est affirmé ici. Parce que l'algorithme de Grover concerne la recherche basée sur le hachage plutôt que la structure de logarithme discret qu'attaque l'algorithme de Shor, les deux menaces nécessitent des défenses totalement séparées : des signatures post-quantiques pour l'une, et essentiellement aucun changement pour l'autre à l'horizon considéré.

Toutes les pièces sur le réseau ne sont pas également exposées même en cas de pire rupture de l'ECDSA. Sur les environ six millions de pièces exposées quantiquement de Bitcoin, seulement environ 2,3 millions sont jugées irréductiblement à risque [2]. Cela importe pour le triage : un plan de transition n'a pas besoin de traiter l'ensemble de l'offre comme également urgent, puisqu'une majorité des pièces exposées pourrait plausiblement être protégée par des mécanismes autres qu'une migration dure immédiate.

Le profil d'exposition d'Ethereum diffère à nouveau. Entre 50 et 65 % de l'Ether se trouve sur des comptes à clé révélée qui peuvent adopter une protection post-quantique [2]. C'est un résultat séparé concernant une chaîne séparée et ne doit pas être transposé au chiffre de 2,3 millions de pièces de Bitcoin, puisque les deux articles décrivent des classes d'actifs différentes et des mécanismes d'exposition différents même s'ils proviennent de la même source [2].

Un article donne des estimations concrètes de matériel et de puissance pour exécuter des attaques de type Grover contre le minage de Bitcoin, ce qui est utile pour ancrer à quel point la technologie actuelle est éloignée d'une attaque pratique sur ce côté du système. Bitcoin fait déjà face à une menace quantique via les attaques de Shor sur les signatures à courbe elliptique, selon cet article [14], ce qui est une redite du même résultat déjà noté ci-dessus [2] plutôt qu'une confirmation indépendante. Dans le cadre de réglage partiel de pré-image le plus favorable considéré par l'article (b = 32, 2^224 états marqués), une flotte de codes de surface supraconducteurs nécessiterait environ 10^8 qubits physiques et environ 10^4 MW [14].

Lorsque le réglage est resserré pour correspondre à la difficulté réelle du réseau principal de Bitcoin en janvier 2025 (b environ 79), la facture de ressources explose à environ 10^23 qubits et environ 10^25 W [14]. Cela dépasse de plusieurs ordres de grandeur le cas le plus favorable, et illustre concrètement pourquoi la preuve de travail est jugée résistante à une accélération quantique à court terme : l'avantage quadratique théorique de l'algorithme de Grover est submergé par les exigences physiques en ressources à une difficulté réaliste.

Ces deux nombres, 10^8 qubits et 10^4 MW dans le cadre favorable contre 10^23 qubits et 10^25 W à la difficulté du réseau principal, proviennent des propres hypothèses de modélisation d'un seul article et doivent être lus comme illustrant l'ampleur de l'écart plutôt que comme une prévision du moment où une telle flotte pourrait exister. Aucune affirmation de cet ensemble ne donne de calendrier pour la construction d'un tel matériel. Un développeur devrait traiter ces nombres comme une vérification d'échelle, pas comme une entrée de plan de projet.

Rien dans cet ensemble de preuves ne donne une estimation comparable du coût matériel pour une attaque par algorithme de Shor sur les signatures ECDSA spécifiquement, donc une comparaison de coût similaire entre attaquer les signatures et attaquer le minage ne peut pas être faite à partir de ces affirmations. L'estimation optimiste de 2027 pour casser l'ECDSA (Section 1) [7] et les coûts matériels de minage ci-dessus [14] proviennent d'articles différents utilisant des méthodes différentes, et ils ne doivent pas être fusionnés en une seule chronologie.

Le processus de normalisation des primitives cryptographiques post-quantiques par le NIST a commencé en décembre 2016 [12]. De ce processus, le NIST a sélectionné trois systèmes de signature numérique pour normalisation : Falcon, SPHINCS+ et CRYSTALS-Dilithium [13], et une revue du domaine met en évidence les trois mêmes algorithmes, CRYSTALS-Dilithium, Falcon et SPHINCS+, comme les clés à suivre dans le processus PQC du NIST [20]. Dilithium en particulier a émergé comme l'un des gagnants de la compétition du NIST et est maintenant normalisé sous le nom ML-DSA (FIPS 204) [12], et il a été identifié comme le choix principal pour la signature numérique post-quantique [13].

La sécurité de Dilithium repose sur trois hypothèses de dureté : Module Learning with Errors (MLWE), Module Short Integer Solution (MSIS) et SelfTargetMSIS [13]. Parmi celles-ci, SelfTargetMSIS est nouveau, et bien qu'il soit classiquement aussi dur que MSIS, sa dureté quantique était auparavant peu claire [13]. Cet écart importe pour quiconque se fie au niveau de sécurité déclaré de Dilithium, car la preuve de dureté classique d'un système ne s'étend pas automatiquement au cadre quantique.

Un article de cet ensemble comble directement cet écart : il fournit la première preuve de la dureté de SelfTargetMSIS, via une réduction de MLWE dans le modèle d'oracle aléatoire quantique (QROM) [13]. Cette nouvelle preuve de sécurité est applicable sous la condition q = 1 mod 2n [13], donc elle ne couvre pas chaque choix de paramètre possible, seulement ceux satisfaisant cette condition modulaire. Un développeur choisissant les paramètres de Dilithium pour une simulation devrait vérifier explicitement cette condition si la preuve de sécurité est censée s'appliquer.

La preuve a un coût en taille. Sous le même niveau de sécurité, la taille de la clé publique et la taille de la signature sont respectivement environ 2,9 fois et 1,3 fois plus grandes que celles proposées par Kiltz et al. [13]. C'est un compromis direct dont un développeur doit tenir compte dans son budget : la garantie de sécurité plus forte et plus complètement prouvée produit des clés et des signatures plus grandes qu'une construction antérieure moins complètement prouvée.

Au-delà des trois systèmes sélectionnés par le NIST, la littérature présente également un compromis plus large entre les familles de systèmes post-quantiques. Les systèmes basés sur les réseaux offrent une meilleure efficacité computationnelle, tandis que les systèmes basés sur les codes offrent des garanties de sécurité plus fortes au prix d'une surcharge de communication accrue [3]. C'est un cadrage général d'un article sur l'authentification MANET, pas un benchmark spécifique à Bitcoin, mais il établit des attentes utiles pour quiconque choisit une famille de système à prototyper : les systèmes basés sur les réseaux plus rapides font un compromis avec les systèmes basés sur les codes plus lourds mais plus conservateurs.

Au sein de la famille des réseaux, CRYSTALS-Dilithium a été testé directement dans un contexte de transaction Bitcoin, avec un inconvénient notable. Un article rapporte que CRYSTALS-Dilithium a la limitation défavorable de faire chuter l'efficacité des transactions Bitcoin de 17 fois [4]. C'est une baisse d'efficacité substantielle, et elle motive le travail sur des constructions plus compactes construites au-dessus de Dilithium plutôt que de l'utiliser non modifié.

Une telle construction est le système LAS proposé dans le même article. Le système LAS proposé, basé sur CRYSTALS-Dilithium et un protocole de connaissances transparentes évolutives sans connaissance (STARK), génère des signatures avec une sécurité post-quantique et de petites tailles de signature [4]. L'affirmation vérifiée ne décrit pas LAS comme une conception de signature agrégée, donc cette note ne le caractérise pas ainsi ; il combine CRYSTALS-Dilithium avec une couche de preuve STARK spécifiquement pour contrer la perte d'efficacité de 17 fois observée avec Dilithium non modifié dans le contexte Bitcoin du même article.

Un article séparé adopte une approche différente, orientée stockage, pour comparer les systèmes dans un cadre d'échange blockchain. Il compare les signatures post-quantiques recommandées par le NIST avec ECDSA dans un système d'échange Bitcoin, enregistrant les valeurs de hachage des signatures et des clés publiques dans la blockchain et stockant leur contenu réel en utilisant IPFS [6]. Cette architecture, hachages sur la chaîne et contenu complet sur IPFS, est un choix de conception distinct de l'approche LAS, visant à contrôler le coût de stockage sur la chaîne plutôt que la taille de signature directement.

Le point de référence le plus directement constructible dans cet ensemble de preuves est une étude de simulation basée sur Python. Dans cet environnement, ECDSA, Falcon, CRYSTALS-Dilithium et SPHINCS+ ont été analysés en combinaison avec les protocoles de communication quantique BB84, E91 et SARG04 [1]. Cet appariement de systèmes de signature post-quantiques avec des protocoles de distribution de clés quantiques est une caractéristique distinctive de cette étude et donne au développeur un modèle de ce qu'il faut simuler et comment structurer la comparaison.

En vitesse brute, le système classique de base gagne toujours, avec une réserve concernant la durabilité. ECDSA reste le système de base le plus rapide mais manque de résistance quantique [1]. C'est le compromis attendu : la signature classique à courbe elliptique est computationnellement bon marché mais n'offre aucune protection une fois qu'un CRQC existe.

Parmi les candidats post-quantiques, SPHINCS+ se distingue par sa sécurité à un coût mesuré. SPHINCS+ offre la sécurité la plus élevée avec une surcharge attendue de 93,5 % [1]. L'article ne précise pas l'unité exacte ou la base de référence par rapport à laquelle ce pourcentage est mesuré (par exemple, s'il s'agit de la taille de la signature, du temps de calcul ou d'une autre métrique), donc un développeur devrait traiter 93,5 % comme un chiffre rapporté à reproduire et à déterminer expérimentalement, plutôt que comme un nombre explicite.

Du côté de la communication quantique, un protocole a été trouvé pour se généraliser le mieux à travers les tailles de transaction. Parmi les protocoles quantiques, BB84 a atteint la meilleure efficacité globale à travers les tailles de transaction [1]. S'appuyant sur cela, l'étude identifie deux paires d'intégration recommandées : BB84 et CRYSTALS-Dilithium pour l'équilibre vitesse/sécurité, et SPHINCS+ et E91 pour une résilience quantique maximale [1]. Ces deux paires donnent au développeur deux configurations de départ concrètes à reproduire, l'une adaptée au débit et l'autre à une sécurité conservative.

Bitcoin ne peut pas simplement échanger son système de signature du jour au lendemain, car les anciennes pièces sont verrouillées sous le système existant et tout changement des règles de consensus nécessite une coordination. Un mécanisme proposé aborde directement ce problème. L'article propose un protocole commit-delay-reveal qui permet aux utilisateurs de déplacer des fonds vers un système de signature résistant quantique, fonctionnant même si ECDSA est compromis, et implémentable comme un soft fork [15]. C'est significatif car cela signifie que le mécanisme de protection ne nécessite pas un hard fork, et qu'il est explicitement conçu pour fonctionner même après que ECDSA ait déjà été cassé, pas seulement comme mesure préventive préalable.

Cette conception commit-delay-reveal est un type de contribution différent des benchmarks de systèmes de signature discutés ailleurs dans cette note. C'est un protocole de migration, concernant la manière dont les pièces passent d'un ancien système à un nouveau dans des conditions adverses, plutôt qu'une comparaison de la vitesse ou de la taille des algorithmes de signature. Un développeur intéressé par la simulation d'une transition complète, pas seulement l'échange de bibliothèques de signatures, devrait considérer cela comme le mécanisme pertinent à prototyper.

Aucune affirmation de cet ensemble ne donne de nombre de performance (latence, débit ou coût de stockage) pour le protocole commit-delay-reveal lui-même. Cela signifie qu'un développeur souhaitant connaître sa surcharge devrait l'implémenter et le mesurer directement, puisque les preuves existantes établissent seulement que le mécanisme existe, quel problème il résout, et qu'il peut être déployé comme un soft fork [15].

Combiner cela avec les chiffres d'exposition discutés plus tôt donne une image plausible (non prouvée comme liée) de triage : une majorité des Bitcoins exposés n'est pas irréductiblement à risque [2], et un chemin de migration compatible soft fork existe pour déplacer les fonds vers des signatures résistantes quantiques [15]. Ces deux résultats proviennent d'articles différents et ne sont liés par aucune affirmation de cet ensemble, donc cette note les présente côte à côte sans affirmer que l'un permet ou a été conçu pour compléter l'autre.

Le plus grand écart unique dans cet ensemble de preuves est l'absence de toute affirmation rapportant un test direct en tête-à-tête d'un système de signature post-quantique intégré dans un nœud Bitcoin réel et en fonctionnement, ou un client complet, sous les règles de consensus réelles de Bitcoin. La preuve la plus proche disponible est un environnement de simulation Python [1] et un système d'échange Bitcoin qui enregistre des hachages sur la chaîne et du contenu sur IPFS [6], tous deux étant des bancs d'essai ou des intégrations partielles plutôt que des déploiements de nœuds complets.

Les estimations du moment où une rupture de l'ECDSA pourrait se produire divergent dans leur cadrage. Un article donne 2027 comme estimation optimiste [7] (voir Section 1), tandis qu'un autre insiste sur le fait qu'aucun CRQC n'existe aujourd'hui et que l'écart jusqu'à un est grand sans donner d'année [2]. Un développeur ne devrait pas faire la moyenne de ces chiffres ou traiter 2027 comme une date attendue ; c'est explicitement le cas le plus optimiste dans son article source [7].

Plusieurs nombres dans cet ensemble manquent de détails méthodologiques complets tels qu'énoncés. Le chiffre de surcharge de 93,5 % pour SPHINCS+ [1] ne spécifie pas son unité ou sa base de référence dans l'affirmation telle que donnée. La baisse d'efficacité de 17 fois pour CRYSTALS-Dilithium dans un contexte de transaction Bitcoin [4] et les augmentations de taille de 2,9 fois et 1,3 fois pour la nouvelle preuve de sécurité de Dilithium par rapport à Kiltz et al. [13] proviennent d'articles différents avec des bases de référence différentes (un contexte d'efficacité de transaction Bitcoin contre une comparaison de taille cryptographique par rapport à une proposition antérieure spécifique) et ne doivent pas être comparés entre eux.

Enfin, aucune affirmation de cet ensemble ne compare directement le coût d'attaquer les signatures de Bitcoin via l'algorithme de Shor contre le coût d'attaquer son minage via l'algorithme de Grover en utilisant les mêmes unités ou hypothèses. Les estimations matérielles du côté du minage [14] et la chronologie de rupture de signature [7] proviennent d'articles séparés avec des méthodes séparées. Toute déclaration classant quelle attaque est plus imminente ou plus gourmande en ressources que l'autre serait une inférence que ces preuves ne soutiennent pas, et cette note a délibérément évité de faire cette comparaison.

1. Définir le périmètre. Décider si le projet est un benchmark de système de signature (suivant le modèle de simulation Python [1]), un test d'intégration de transaction Bitcoin (suivant l'approche CRYSTALS-Dilithium et LAS [4]), ou un test d'architecture de stockage (suivant la conception hachage-sur-chaîne, contenu-sur-IPFS [6]). Ce sont trois formes de projet distinctes tirées de trois articles différents ; en choisir une pour éviter de confondre leurs méthodes.
2. Choisir les systèmes de signature à implémenter. Au minimum, implémenter ECDSA comme base de référence, plus les trois systèmes post-quantiques sélectionnés par le NIST : Falcon, SPHINCS+ et CRYSTALS-Dilithium [13] [1]. Utiliser des implémentations de référence pour chacun ; ne pas écrire de nouvelles primitives cryptographiques à partir de zéro.
3. Vérifier les conditions des paramètres avant de se fier à une preuve de sécurité. Si vous utilisez Dilithium et citez sa preuve de sécurité QROM, confirmer que le choix de paramètre satisfait q = 1 mod 2n [13], puisque la preuve dans cet article est déclarée applicable seulement sous cette condition.
4. Construire le harnais de simulation en Python. Suivre la structure de l'étude de référence, qui a analysé ECDSA, Falcon, CRYSTALS-Dilithium et SPHINCS+ en combinaison avec les protocoles de communication quantique BB84, E91 et SARG04 [1]. Faire varier la taille de transaction comme paramètre expérimental, puisque l'étude de référence a mesuré l'efficacité à travers les tailles de transaction [1].
5. Mesurer la vitesse par rapport à la base de référence ECDSA. Enregistrer le temps de signature et de vérification pour chaque système post-quantique par rapport à ECDSA. S'attendre à ce qu'ECDSA reste le plus rapide [1] ; l'objectif est de quantifier de combien chaque candidat post-quantique est plus lent sous votre propre matériel et implémentation, puisque l'article de référence rapporte le classement mais un développeur a besoin de ses propres nombres reproductibles.
6. Mesurer et rapporter la surcharge avec précision. Lors de la mesure de SPHINCS+, rapporter la surcharge avec une unité explicite, par exemple octets de taille de signature, ou millisecondes de temps de calcul, ou bande passante. Le chiffre de référence de 93,5 % de surcharge [1] ne spécifie pas son unité dans l'affirmation telle que donnée, donc définissez la vôtre clairement pour rendre le résultat reproductible et comparable.
7. Tester les deux paires recommandées. Reproduire les deux configurations d'intégration de l'étude de référence : BB84 avec CRYSTALS-Dilithium pour un équilibre vitesse/sécurité, et SPHINCS+ avec E91 pour une résilience quantique maximale [1]. Comparer les deux à la base de référence ECDSA seule sur la même charge de travail de transaction.
8. Si vous testez dans un contexte de transaction Bitcoin, mesurer directement l'efficacité des transactions. Des travaux antérieurs ont trouvé que CRYSTALS-Dilithium faisait chuter l'efficacité des transactions Bitcoin de 17 fois lorsqu'il est utilisé directement [4]. Confirmer si votre implémentation reproduit une baisse similaire, et si c'est le cas, envisager si un wrapper de signature agrégée ou basé sur STARK, suivant la conception LAS [4], vaut la peine d'être implémenté pour récupérer l'efficacité.
9. Si vous testez une architecture de stockage, séparer explicitement les données sur la chaîne et hors chaîne. Suivant la conception du système d'échange, stocker les valeurs de hachage des signatures et des clés publiques sur la chaîne, et stocker le contenu réel de la signature et de la clé sur IPFS [6]. Mesurer séparément la croissance du stockage sur la chaîne et la latence de récupération IPFS.
10. Si vous testez un mécanisme de migration, implémenter le flux commit-delay-reveal. Ce protocole permet aux utilisateurs de déplacer des fonds vers un système résistant quantique et est conçu pour fonctionner comme un soft fork, même si ECDSA a déjà été compromis [15]. Simuler les phases de commit, delay et reveal sur un testnet ou une chaîne privée, et mesurer l'effet de la fenêtre de délai sur l'expérience utilisateur et sur l'opportunité d'attaque, puisque aucune source de cet ensemble ne rapporte directement cette surcharge.
11. Rapporter chaque nombre avec ses conditions expérimentales exactes. Énoncer le benchmark, l'échantillon ou la charge de travail, et le cadre logiciel/matériel pour chaque valeur mesurée, suivant le modèle utilisé tout au long de cette note ; ne pas rapporter un pourcentage ou un multiplicateur nu sans le contexte déclaré de son article source.
12. Points de défaillance courants à vérifier. Confirmer que les versions de bibliothèque de Dilithium, Falcon et SPHINCS+ correspondent aux ensembles de paramètres référencés dans les documents de normalisation [13] [12] ; confirmer la condition modulaire de la preuve QROM si vous vous y fiez [13] ; et garder la menace de minage liée à l'algorithme de Grover totalement séparée du travail de benchmark des systèmes de signature, car ils traitent de différentes parties du système avec différents modèles d'attaque [2].