Calcul quantique et blockchain : aligner l’urgence sur la menace réelle

Rédigé par : Justin Thaler

Traduction : Biaohua Blockchain

Le calendrier des ordinateurs quantiques applicables à la cryptographie est souvent exagéré – ce qui conduit à exiger une transition urgente et généralisée vers la cryptographie post-quantique.

Cependant, ces appels ignorent souvent les coûts et risques d’une migration prématurée, et négligent les profils de risque très différents entre les primitives cryptographiques :

La cryptographie post-quantique exige, malgré son coût, un déploiement immédiat : les attaques « récolter maintenant, décrypter plus tard » (Harvest-Now-Decrypt-Later, HNDL) sont déjà en cours, car les données sensibles chiffrées aujourd’hui garderont leur valeur quand les ordinateurs quantiques arriveront, même si ce n’est que dans plusieurs décennies. Les surcoûts de performance et les risques de mise en œuvre de la cryptographie post-quantique sont réels, mais les attaques HNDL ne laissent pas d’alternative pour les données nécessitant une confidentialité à long terme.

Les signatures post-quantiques soulèvent d’autres considérations. Elles ne sont pas vulnérables aux attaques HNDL, et leur coût et risques (taille accrue, surcoûts de performance, maturité des implémentations et bugs) imposent une réflexion approfondie plutôt qu’une migration immédiate.

Ces distinctions sont cruciales. Les malentendus faussent l’analyse coût-bénéfice et font ignorer à des équipes des risques de sécurité plus pressants – comme les bugs logiciels.

Le vrai défi pour une transition réussie vers la cryptographie post-quantique réside dans l’alignement de l’urgence sur la réalité de la menace. Ci-dessous, j’éclaircis les idées reçues courantes sur la menace quantique pour la cryptographie – couvrant chiffrement, signatures et preuves à connaissance nulle – et je m’attarde en particulier sur leur impact pour la blockchain.

Où en sommes-nous sur le calendrier ?

Malgré ce qui est fréquemment relayé, il est extrêmement improbable que des ordinateurs quantiques capables de casser la cryptographie apparaissent dans les années 2020.

Par « ordinateur quantique pertinent pour la cryptographie », j’entends une machine quantique tolérante aux fautes, avec correction d’erreurs, capable d’exécuter l’algorithme de Shor à une échelle suffisante pour casser {secp}256{k}1 ou {RSA-2048} (crypto à courbe elliptique ou RSA) en un temps raisonnable (par exemple, moins d’un mois de calcul continu).

D’après toute lecture raisonnable des avancées publiques et des ressources estimées, nous sommes encore loin d’un ordinateur quantique de ce type. Certaines entreprises prétendent qu’un CRQC pourrait exister d’ici 2030 ou 2035, mais les progrès publiquement connus ne soutiennent pas ces affirmations.

Pour donner un contexte, dans toutes les architectures actuelles – ions piégés, qubits supraconducteurs et systèmes d’atomes neutres – les plateformes quantiques d’aujourd’hui ne sont pas proches du nombre de qubits physiques (centaines de milliers à millions, selon les taux d’erreur et les codes de correction) nécessaires pour exécuter l’algorithme de Shor contre {RSA-2048} ou {secp}256{k}1.

Les limitations ne concernent pas seulement la quantité de qubits, mais aussi la fidélité des portes, la connectivité des qubits et la profondeur des circuits de correction d’erreur nécessaires pour des algorithmes quantiques complexes. Certains systèmes dépassent maintenant 1 000 qubits physiques, mais ce chiffre peut être trompeur : ils n’ont pas la connectivité ni la fidélité requises pour le calcul cryptographique.

Les systèmes récents approchent du taux d’erreur physique où la correction d’erreurs quantiques commence à fonctionner, mais personne n’a démontré plus que quelques qubits logiques avec une profondeur de circuit de correction soutenue… encore moins les milliers de qubits logiques tolérants aux fautes, haute fidélité et circuits profonds nécessaires pour Shor. Le fossé entre la faisabilité théorique de la correction d’erreurs et l’échelle requise pour la cryptanalyse reste immense.

En résumé : à moins que la quantité et la qualité des qubits n’augmentent de plusieurs ordres de grandeur, un ordinateur quantique pertinent pour la cryptographie reste hors de portée.

Néanmoins, les communiqués d’entreprise et articles de presse prêtent à confusion. Voici quelques sources fréquentes de malentendus :

Démonstrations de « suprématie quantique » sur des tâches artificielles, choisies non pour leur utilité mais pour leur exécution sur le matériel actuel, et présentées comme une percée majeure – ce qui est souvent flou dans l’annonce.

La proclamation de « milliers de qubits physiques » se réfère souvent à des machines à recuit quantique, non au modèle de portes nécessaire pour attaquer la cryptographie à clé publique avec Shor.

L’usage abusif du terme « qubit logique ». Les qubits physiques sont bruités. Les algorithmes quantiques nécessitent des qubits logiques ; Shor en exige des milliers. Par la correction d’erreurs, on réalise un qubit logique avec des centaines à milliers de qubits physiques (selon le taux d’erreur). Certaines entreprises déforment ce terme, allant jusqu’à prétendre qu’un code de distance 2, utilisant seulement deux qubits physiques, donne un qubit logique – ce qui est absurde : un code de distance 2 détecte des erreurs, mais ne les corrige pas. Un qubit logique tolérant aux fautes réel pour la cryptanalyse nécessite des centaines à milliers de qubits physiques, jamais deux.

Plus généralement, beaucoup de feuilles de route quantiques parlent de « qubits logiques » ne supportant que des opérations Clifford, qui sont simulables classiquement et insuffisants pour Shor – qui requiert des milliers de portes T corrigées (ou plus généralement, de portes non-Clifford).

Même si une feuille de route vise « des milliers de qubits logiques d’ici X années », cela ne signifie pas que l’entreprise prévoit d’exécuter Shor à l’échelle cryptographique à l’année X.

Ces pratiques faussent sérieusement la perception, même parmi les observateurs aguerris, de notre proximité avec un ordinateur quantique pertinent pour la cryptographie.

Cela dit, certains experts restent enthousiastes. Par exemple, Scott Aaronson écrivait récemment, vu « le rythme actuel stupéfiant du matériel » :

Je pense maintenant qu’il est réaliste d’avoir un ordinateur quantique tolérant aux fautes exécutant Shor avant la prochaine élection présidentielle américaine.

Mais Aaronson a ensuite précisé qu’il ne parlait pas d’un CRQC : il considère qu’une exécution complète de Shor factorisant 15 = 3 × 5 suffit – un calcul faisable plus rapidement à la main. La norme reste l’exécution à petite échelle de Shor, pas à l’échelle cryptographique : les expériences précédentes de factorisation de 15 sur ordinateur quantique utilisaient des circuits simplifiés, pas la version complète et tolérante aux fautes. Et il y a une raison pour laquelle ces expériences ciblent toujours 15 : l’arithmétique modulo 15 est facile, alors que factoriser 21 est déjà bien plus difficile – d’où l’usage d’astuces ou d’aides additionnelles pour 21.

En bref, il n’y a pas de progrès publiquement connu suggérant qu’un CRQC capable de casser {RSA-2048} ou {secp}256{k}1, ce qui serait crucial pour la cryptographie appliquée, puisse apparaître dans les 5 prochaines années.

Même 10 ans reste ambitieux. Vu l’état d’avancement, l’enthousiasme est cohérent avec un horizon supérieur à dix ans.

Qu’en est-il alors de la date butoir de 2035 fixée par le gouvernement américain pour une migration post-quantique (PQ) complète de ses systèmes ? Je considère ce calendrier raisonnable pour un changement d’une telle ampleur. Cela ne signifie pas que l’on prédit l’arrivée d’un CRQC à cette date.

Dans quels cas les attaques HNDL sont-elles applicables (et non applicables) ?

Les attaques « récolter maintenant, décrypter plus tard » (HNDL) désignent l’action d’un adversaire qui archive le trafic chiffré aujourd’hui, pour le décrypter le jour où un CRQC existera. Les adversaires de niveau étatique archivent très probablement à grande échelle les communications chiffrées du gouvernement US, en vue de les décrypter des années après l’arrivée d’un CRQC.

C’est pourquoi le chiffrement doit migrer immédiatement – du moins pour toute information devant rester confidentielle sur 10 à 50 ans ou plus.

Mais la signature numérique – sur laquelle reposent toutes les blockchains – diffère : il n’existe pas d’attaque de confidentialité rétroactive.

Autrement dit, si un CRQC arrive, la falsification de signatures devient possible à partir de ce moment, mais les signatures passées ne « cachent » pas de secret comme un message chiffré. Tant que l’on sait qu’une signature a été générée avant l’arrivée d’un CRQC, elle ne peut pas être contrefaite.

La transition vers les signatures numériques post-quantiques est donc moins urgente que celle du chiffrement.

Les principales plateformes agissent en conséquence : Chrome et Cloudflare ont déployé le chiffrement hybride {X}25519+{ML-KEM} pour TLS.

Dans cet article, par souci de lisibilité, je parle de « chiffrement », bien que techniquement les protocoles comme TLS utilisent plutôt l’échange ou l’encapsulation de clés que le chiffrement à clef publique.

Ici, « hybride » signifie l’utilisation simultanée d’un schéma post-quantique (ML-KEM) et d’un schéma classique ({X}25519), combinant leurs garanties de sécurité. Ainsi, on peut (espérer) bloquer les attaques HNDL via ML-KEM, tout en restant sécurisé classiquement si ML-KEM s’avère vulnérable aux ordinateurs classiques.

Apple a également déployé ce type de chiffrement hybride post-quantique dans iMessage via son protocole PQ3, et Signal le fait via PQXDH et SPQR.

En revanche, la généralisation des signatures numériques post-quantiques dans l’infrastructure réseau critique est repoussée tant que le CRQC n’est pas imminent, car les schémas actuels de signature post-quantique engendrent des coûts de performance (détaillés plus loin).

Les zkSNARKs – preuves succinctes non-interactives à connaissance nulle, clé de la confidentialité et de la scalabilité à long terme des blockchains – sont dans une situation similaire. En effet, même les {zkSNARKs} non post-quantiques (utilisant la cryptographie à courbe elliptique, comme les schémas classiques de chiffrement et de signature) restent post-quantiques sur le plan de la confidentialité.

La propriété de connaissance nulle garantit qu’aucune information sur le témoin secret n’est révélée par la preuve – même face à un adversaire quantique – donc aucun secret n’est « récoltable » pour un décryptage ultérieur.

Les {zkSNARKs} ne sont donc pas vulnérables aux attaques HNDL. De même que les signatures classiques générées aujourd’hui sont sûres, toutes les preuves {zkSNARK} produites avant l’arrivée d’un CRQC restent fiables (l’énoncé prouvé est vrai), même si {zkSNARK} repose sur la cryptographie à courbe elliptique. Ce n’est qu’après l’arrivée du CRQC qu’un adversaire pourrait fabriquer une preuve pour un énoncé faux.

Conséquences pour la blockchain

La plupart des blockchains ne sont pas exposées aux attaques HNDL :

La plupart des chaînes non-privées, comme Bitcoin et Ethereum aujourd’hui, utilisent la cryptographie classique essentiellement pour l’autorisation des transactions – c’est-à-dire les signatures numériques, pas le chiffrement.

De même, ces signatures ne présentent pas de risque HNDL : une attaque « récolter maintenant, décrypter plus tard » vise les données chiffrées. Par exemple, la blockchain Bitcoin est publique ; la menace quantique est la falsification de signature (dérivation de la clé privée pour voler des fonds), pas le décryptage de données de transaction déjà publiques. Cela supprime l’urgence d’une migration du chiffrement liée à HNDL.

Malheureusement, même des analyses émanant d’autorités crédibles comme la Fed ont à tort affirmé que Bitcoin était vulnérable à HNDL, ce qui exagère l’urgence de la transition post-quantique.

Cela dit, une urgence moindre ne signifie pas que Bitcoin peut attendre : il fait face à une pression temporelle différente liée à la coordination sociale massive requise pour tout changement de protocole.

À ce jour, l’exception concerne les chaînes de confidentialité, dont beaucoup chiffrent ou cachent autrement les destinataires et les montants. Une fois que les ordinateurs quantiques pourront casser la cryptographie à courbe elliptique, cette confidentialité peut être récoltée dès aujourd’hui, puis rétroactivement rompue.

La gravité de l’attaque dépend du design de la chaîne. Par exemple, pour Monero, les signatures en anneau et images de clé basées sur les courbes (étiquettes de lien pour chaque sortie afin d’éviter la double dépense) permettent, à partir du registre public, de reconstruire rétroactivement le graphe des dépenses. Sur d’autres chaînes, l’impact est plus limité – voir la discussion de Sean Bowe, ingénieur cryptographe chez Zcash.

Si la confidentialité des transactions face à un CRQC est essentielle, les chaînes privées devraient migrer vers des primitives post-quantiques (ou hybrides) dès que possible. Ou alors, adopter une architecture évitant de placer sur la chaîne des secrets déchiffrables.

Le cas particulier de Bitcoin : gouvernance + coins abandonnés

Pour Bitcoin en particulier, deux réalités rendent urgente la planification de la transition vers les signatures post-quantiques. Aucune n’est liée à la technologie quantique.

La première est la lenteur de gouvernance : Bitcoin évolue lentement. Si la communauté ne s’accorde pas sur une solution, tout sujet controversé peut entraîner un hard fork destructeur.

La seconde est que la migration post-quantique ne peut pas être passive : les détenteurs doivent migrer activement leurs coins. Les coins abandonnés, vulnérables quantiquement, ne peuvent être protégés. Selon certaines estimations, plusieurs millions de BTC sont dans ce cas, soit des dizaines de milliards de dollars (au prix courant de décembre 2025).

Cependant, la menace quantique pour Bitcoin ne sera pas une catastrophe soudaine et globale… mais un processus progressif et sélectif. Un ordinateur quantique ne cassera pas toute la crypto d’un coup – l’algorithme de Shor cible une clé publique à la fois. Les premières attaques quantiques seront très coûteuses et lentes. Dès qu’un ordinateur quantique pourra casser une clé de signature Bitcoin, les attaques cibleront les portefeuilles à forte valeur.

De plus, les utilisateurs évitant la réutilisation d’adresse et n’utilisant pas d’adresses Taproot (qui exposent directement la clé publique sur la chaîne) sont largement protégés même sans changement de protocole : leur clé publique reste cachée par une fonction de hachage tant que les coins ne sont pas dépensés. Lorsqu’ils effectuent une dépense, la clé publique est révélée, et il y a alors une brève course en temps réel entre le détenteur honnête cherchant la confirmation de la transaction et un attaquant équipé quantiquement cherchant à extraire la clé privée et à dépenser les coins. Les coins réellement vulnérables sont donc ceux dont la clé publique est déjà exposée : premières sorties pay-to-pubkey, adresses réutilisées et détentions Taproot.

Pour les coins abandonnés vulnérables, il n’existe pas de solution simple. Quelques options :

La communauté Bitcoin s’accorde sur une « date de coupure » après laquelle tout coin non migré est déclaré détruit.

Les coins vulnérables abandonnés deviennent récupérables par quiconque dispose d’un CRQC.

Cette seconde option pose de sérieux problèmes juridiques et de sécurité. S’emparer de coins sans clé privée via un ordinateur quantique – même pour des motifs légitimes – peut constituer un vol ou une fraude informatique dans de nombreuses juridictions.

En outre, la notion d’« abandon » repose sur une présomption d’inactivité. Personne ne sait réellement si ces coins appartiennent à des détenteurs vivants. Prouver que vous possédiez autrefois ces coins peut ne pas suffire à justifier légalement de casser leur protection. Cette incertitude juridique accroît le risque que des coins vulnérables tombent aux mains de personnes peu soucieuses des lois.

Autre problème propre à Bitcoin : son faible débit transactionnel. Même si un plan de migration est arrêté, transférer tous les fonds vulnérables vers des adresses post-quantiques sécurisées prendrait des mois au rythme actuel.

Ces défis rendent crucial pour Bitcoin d’amorcer dès maintenant la planification de sa migration post-quantique – non parce que le CRQC arrivera avant 2030, mais parce que la gouvernance, la coordination et la logistique technique nécessaires pour migrer des dizaines de milliards de dollars prendront des années.

La menace quantique sur Bitcoin est réelle, mais la pression temporelle relève des limitations propres à Bitcoin, non d’une urgence quantique. D’autres blockchains ont leur lot de fonds vulnérables, mais Bitcoin est singulièrement exposé : ses toutes premières transactions utilisaient des sorties pay-to-pubkey, exposant directement la clé publique sur la chaîne, ce qui rend une part importante des BTC particulièrement vulnérable à un CRQC. Cette spécificité, combinée à l’ancienneté, la concentration de valeur, le faible débit et la rigidité de gouvernance, aggrave le problème.

Notez que les faiblesses décrites ci-dessus concernent la sécurité cryptographique des signatures Bitcoin – pas la sécurité économique de la blockchain. Cette dernière, issue du consensus Preuve de Travail (PoW), est peu vulnérable aux ordinateurs quantiques pour trois raisons :

Le PoW repose sur le hachage, donc n’est affecté que par l’accélération quadratique de Grover, pas l’exponentielle de Shor.

Les surcoûts réels d’implémentation de Grover rendent improbable tout avantage quantique notable pour le PoW de Bitcoin.

Même un tel avantage ne profiterait qu’aux plus gros mineurs quantiques, sans remettre en cause le modèle économique fondamental de Bitcoin.

Coûts et risques des signatures post-quantiques

Pour comprendre pourquoi la blockchain ne doit pas précipiter le déploiement des signatures post-quantiques, il faut évaluer les coûts de performance et la confiance encore évolutive dans leur sécurité.

La majorité des primitives post-quantiques repose sur l’une de cinq approches :

hachage (hashing),

codes (codes),

réseaux (lattices),

systèmes multivariés quadratiques (multivariate quadratic systems, MQ),

isogénies (isogenies).

Pourquoi cinq approches différentes ? La sécurité d’une primitive post-quantique repose sur l’hypothèse qu’un ordinateur quantique ne peut résoudre efficacement un certain problème mathématique. Plus ce problème est « structuré », plus les protocoles cryptographiques construits dessus sont efficaces.

Mais cela a un revers : trop de structure facilite l’apparition d’algorithmes d’attaque. On retrouve donc une tension fondamentale : des hypothèses fortes offrent de meilleures performances, mais au prix d’un risque accru de vulnérabilité (si l’hypothèse s’avère fausse).

En général, les méthodes à base de hachage sont les plus conservatrices en matière de sécurité, car nous avons le plus confiance dans leur résistance quantique. Mais elles sont les moins performantes. Par exemple, le schéma de signature à base de hachage standardisé par le NIST, même en paramètre minimal, fait 7-8 Ko. À comparer aux signatures à courbe elliptique actuelles de 64 octets – soit 100 fois moins.

Les schémas à base de réseaux sont aujourd’hui l’axe principal de déploiement. Le NIST a sélectionné pour standardisation la seule primitive de chiffrement et deux des trois schémas de signature, tous à base de réseaux. Un schéma (ML-DSA, ex-Dilithium) produit des signatures de 2,4 Ko (sécurité 128 bits) à 4,6 Ko (256 bits) – soit 40 à 70 fois plus que les signatures à courbe elliptique. Un autre, Falcon, offre des signatures plus petites (Falcon-512 : 666 octets, Falcon-1024 : 1,3 Ko), mais implique des calculs flottants complexes, que le NIST juge difficiles à implémenter. Thomas Pornin, l’un de ses créateurs, le décrit comme « l’algorithme cryptographique le plus complexe que j’aie implémenté ».

Côté sécurité d’implémentation, les signatures à base de réseaux sont plus délicates que les signatures à courbe elliptique : ML-DSA implique plus de variables intermédiaires sensibles et une logique d’échantillonnage avec rejets, nécessitant protections contre canaux cachés et fautes. Falcon ajoute des problèmes de calcul flottant en temps constant ; plusieurs attaques par canaux cachés ont déjà permis d’extraire des clés Falcon.

Ces problèmes constituent un risque immédiat, non spéculatif, contrairement à la menace lointaine des ordinateurs quantiques.

La prudence est donc de mise avant de déployer des méthodes post-quantiques à meilleure performance. Historiquement, des candidats de tête comme Rainbow (schéma de signature MQ) et SIKE/SIDH (schéma de chiffrement à base d’isogénies) ont été cassés classiquement, c’est-à-dire avec les ordinateurs actuels, et ce tard dans le processus de standardisation du NIST. C’est sain scientifiquement, mais montre qu’une standardisation ou un déploiement prématuré peuvent se retourner contre vous.

Comme mentionné, l’infrastructure Internet adopte une approche réfléchie pour la migration des signatures. C’est d’autant plus pertinent que la transition du chiffrement sur Internet, une fois lancée, prend des années. Les transitions passées, comme celles de MD5 ou SHA-1 (abandonnés depuis longtemps en théorie), continuent à traîner dans les infrastructures. Cela alors même que ces schémas sont totalement cassés, non simplement potentiellement vulnérables à une technologie future.

Spécificités de la blockchain face à l’infrastructure Internet

Heureusement, les blockchains maintenues activement par des communautés open source, comme Ethereum ou Solana, peuvent évoluer plus vite que l’infrastructure Internet traditionnelle. Mais cette dernière bénéficie de rotations fréquentes de clés, ce qui fait évoluer sa surface d’attaque plus vite que ce qu’un ordinateur quantique pourra cibler – un luxe que la blockchain n’a pas, les fonds et clés pouvant rester exposés indéfiniment.

Globalement, la blockchain devrait donc suivre la même approche réfléchie pour la migration des signatures. Dans les deux cas, elles ne sont pas exposées aux attaques HNDL et, quelle que soit la durée de vie des clés, le coût et le risque d’une migration prématurée vers des schémas post-quantiques immatures sont élevés.

Certains défis propres à la blockchain rendent la migration prématurée particulièrement risquée et complexe : par exemple, la nécessité de pouvoir agréger rapidement de nombreuses signatures. Aujourd’hui, les signatures BLS sont largement utilisées pour leur agrégation rapide, mais elles ne sont pas post-quantiques. La recherche sur l’agrégation post-quantique à base de SNARKs est prometteuse, mais encore préliminaire.

Concernant les SNARKs, la communauté mise actuellement sur les constructions à base de hachage comme option post-quantique de tête. Mais un changement majeur s’annonce : dans les mois et années à venir, des options à base de réseaux devraient devenir une alternative attractive, offrant de meilleures performances (preuves plus courtes, etc.), de la même façon que les signatures à base de réseaux sont plus compactes que celles à base de hachage.

Le problème plus pressant : la sécurité de l’implémentation

Dans les prochaines années, les bugs d’implémentation seront un risque de sécurité bien plus grand que les CRQC. Pour les {SNARKs}, le principal souci reste les bugs logiciels.

Les bugs sont déjà un défi pour les signatures et schémas de chiffrement ; or les {SNARKs} sont bien plus complexes. En fait, une signature numérique peut se voir comme un {zkSNARK} très simple pour « je connais la clé privée associée à ma clé publique et j’autorise ce message ».

Pour les signatures post-quantiques, les risques immédiats incluent aussi les attaques d’implémentation, comme les attaques par canaux cachés ou injection de fautes, qui sont bien documentées et permettent de récupérer des clés dans des systèmes en production. Elles constituent une menace plus pressante que les ordinateurs quantiques à venir.

La communauté devra passer des années à identifier et corriger les bugs dans les {SNARKs}, et à renforcer les signatures post-quantiques contre les attaques par canaux cachés et fautes. Puisque les constructions post-quantiques pour {SNARKs} et l’agrégation de signatures ne sont pas encore stabilisées, une migration trop rapide risquerait de figer l’écosystème dans des schémas sous-optimaux, ou d’imposer une deuxième migration lors de la découverte de meilleures options ou de failles.

Que faire ? 7 recommandations

Au vu des réalités exposées ci-dessus, voici mes conseils pour les différentes parties prenantes – développeurs, décideurs politiques, etc. Principe de base : prenez la menace quantique au sérieux, mais n’agissez pas comme si un CRQC arriverait avant 2030. Rien ne le corrobore à ce jour. Néanmoins, voici ce que nous pouvons et devons faire dès maintenant :

Déployez immédiatement le chiffrement hybride.

Ou du moins, là où la confidentialité à long terme est importante et que le coût est acceptable.

De nombreux navigateurs, CDN et messageries (iMessage, Signal) ont déjà déployé l’approche hybride. Les méthodes hybrides – post-quantique + classique – permettent de bloquer les attaques HNDL, tout en couvrant les faiblesses potentielles des schémas post-quantiques.

Utilisez immédiatement les signatures à base de hachage là où leur taille est acceptable.

Les mises à jour logicielles/firmware, et autres scénarios peu fréquents et peu sensibles à la taille, devraient adopter sans attendre les signatures hybrides à base de hachage (l’hybride vise à couvrir les bugs d’implémentation, non à cause de doutes sur la sécurité du hachage).

C’est une mesure conservatrice, qui offre à la société un « canot de sauvetage » si un CRQC arrivait plus tôt qu’attendu. Sans signatures post-quantiques dans les mises à jour logicielles, à l’arrivée du CRQC, nous ne pourrions plus distribuer en toute sécurité les correctifs cryptographiques nécessaires.

La blockchain n’a pas besoin de déployer en urgence les signatures post-quantiques – mais doit planifier dès maintenant.

Les développeurs blockchain devraient suivre l’exemple de la communauté PKI Internet et adopter une approche réfléchie. Cela permet aux schémas post-quantiques de mûrir en performance et sécurité, et donne le temps de réarchitecturer les systèmes pour gérer des signatures plus grandes et développer de meilleures techniques d’agrégation.

Pour Bitcoin et autres L1 : la communauté doit définir le chemin de migration et la politique sur les fonds vulnérables abandonnés. La migration passive n’est pas possible, donc la planification est cruciale. Bitcoin fait face à des défis non techniques particuliers (gouvernance lente, masse de fonds vulnérables d’une grande valeur), d’où la nécessité de commencer dès maintenant.

Parallèlement, il faut laisser mûrir la recherche sur les {SNARKs} post-quantiques et les schémas d’agrégation de signatures (ce qui prendra encore quelques années). Encore une fois, la migration prématurée risque de figer des choix sous-optimaux ou d’imposer une deuxième migration.

Note sur le modèle de compte Ethereum : Ethereum propose deux types de comptes, impactant différemment la migration post-quantique – comptes externes (EOAs), contrôlés par clé privée {secp}256{k}1 ; et portefeuilles smart contract à logique d’autorisation programmable.

En situation non urgente, si Ethereum ajoute le support de signatures post-quantiques, les portefeuilles smart contract upgradables pourront changer de schéma via mise à jour du contrat, alors que les EOAs devront transférer leurs fonds vers de nouvelles adresses post-quantiques (même si Ethereum proposera sans doute une mécanique dédiée pour migrer les EOAs).

En cas d’urgence quantique, les chercheurs Ethereum ont proposé un hard fork pour geler les comptes vulnérables, puis permettre aux utilisateurs de récupérer leurs fonds via une preuve {SNARKs} post-quantique de connaissance de la phrase mnémonique – applicable aux EOAs et aux smart contracts non encore mis à jour.

Impact concret pour les utilisateurs : un portefeuille smart contract upgradable et bien audité offre une migration légèrement plus fluide – mais la différence est faible, et implique une confiance dans le fournisseur de wallet et la gouvernance des mises à jour. Il est plus important que la communauté Ethereum poursuive son travail sur les primitives post-quantiques et les plans d’urgence.

Leçon de design plus générale pour les développeurs : de nombreuses blockchains lient aujourd’hui l’identité du compte à une primitive cryptographique spécifique – Bitcoin et Ethereum avec ECDSA sur {secp}256{k}1, d’autres chaînes avec EdDSA. La difficulté de migration post-quantique souligne l’intérêt de découpler l’identité du compte de tout schéma de signature particulier. La transition d’Ethereum vers les comptes smart et des travaux similaires sur l’abstraction de compte ailleurs vont dans ce sens : permettre à un compte d’évoluer dans sa logique d’authentification sans perdre son historique et état on-chain. Ce découplage ne rend pas la migration triviale, mais offre bien plus de flexibilité que d’encoder en dur un schéma dans le compte (et cela permet aussi sponsorisation de transactions, récupération sociale, multi-signatures, etc.).

Pour les chaînes de confidentialité qui chiffrent ou cachent les détails de transaction, une migration plus précoce doit être priorisée si la performance le permet.

La confidentialité des utilisateurs sur ces chaînes est exposée aux attaques HNDL, même si la gravité varie selon le design. Celles permettant une dé-anonymisation rétroactive complète rien qu’avec la chaîne publique sont les plus à risque.

Envisagez des schémas hybrides (post-quantique + classique) pour éviter qu’un schéma post-quantique ne se révèle même non sécurisé classiquement, ou des changements d’architecture pour ne plus mettre de secrets déchiffrables on-chain.

À court terme, priorisez la sécurité d’implémentation – et non l’atténuation des menaces quantiques.

Pour les primitives complexes comme {SNARKs} et les signatures post-quantiques, les bugs logiciels et attaques d’implémentation (canaux cachés, fautes) seront un risque bien supérieur aux CRQC dans les prochaines années.

Investissez dans les audits, le fuzzing, la vérification formelle, la défense en profondeur – ne laissez pas l’angoisse quantique vous détourner des bugs bien plus pressants !

Financez le développement du calcul quantique.

Un enjeu clé de sécurité nationale est de continuer à financer et former des talents en calcul quantique.

Qu’un adversaire majeur atteigne la capacité quantique cryptographique avant les États-Unis constituerait un risque stratégique grave.

Gardez du recul sur les annonces quantiques.

À mesure que le matériel progresse, de multiples jalons médiatisés apparaîtront. Paradoxalement, leur fréquence prouve que le CRQC reste lointain : chaque jalon n’est qu’un des nombreux ponts à franchir, chacun générant son lot de manchettes.

Considérez les communiqués comme des rapports de progrès à juger de façon critique, non comme des alertes à action immédiate.

Bien sûr, il peut y avoir des percées ou des innovations qui accélèrent le calendrier, autant que des goulets d’étranglement qui le ralentissent.

Je ne prétends pas qu’un CRQC dans cinq ans soit absolument impossible – juste extrêmement improbable. Les recommandations ci-dessus sont robustes face à cette incertitude, et leur suivi permet d’éviter les risques plus immédiats et plus probables : bugs, déploiements précipités et les ratés habituels des transitions cryptographiques.

BTC1.68%
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • Commentaire
  • Reposter
  • Partager
Commentaire
0/400
Aucun commentaire
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)