security : La dérivation de clé rend-elle (ou aide-t-elle à rendre) Bitcoin "quantum safe"  ?


Je me demandais si l’utilisation d’une adresse par transaction réduirait ce problème

Le temps entre la diffusion de la transaction de dépense et son enfouissement suffisant dans la chaîne expose toujours l’utilisateur à des risques s’il existe des machines hypothétiques capables de calculer le logarithme discret vous ne pouvez pas faire d’hypothèses sur la vitesse à laquelle cela fonctionnerait.

De plus, de nombreux cas d’utilisation de Bitcoin impliquent le partage de clés publiques avec d’autres parties non entièrement fiables. Par exemple, les portefeuilles multisig nécessitent que les clés publiques soient partagées entre les participants. Les clients légers révèlent les clés publiques aux serveurs qui les aident à suivre leur solde. Les canaux Lightning impliquent des clés publiques de nœud partagé et des clés publiques de canal sur le réseau. En présence d’un matériel hypothétique capable de calculer des clés privées, le Bitcoin tel qu’il est utilisé aujourd’hui cesserait pratiquement d’exister, car tous ces cas d’utilisation disparaissent.

security : La dérivation de clé rend-elle (ou aide-t-elle à rendre) Bitcoin

vous devez considérer qu’une énorme quantité de BTC est actuellement détenue dans des adresses dont les clés publiques sont connues, même si ce ne sont pas vos fonds. En présence d’une hypothétique machine à casser EC, tant de fonds seraient exposés que je ne peux pas imaginer que BTC conserve une grande valeur.

Je me demandais si l’utilisation d’une adresse par transaction atténuerait ce problème, car apparemment les fonctions de dérivation de clé (bcrypt, Scrypt, Argon2) sont fondamentalement sûres quantiques. Mon raisonnement est qu’à partir de votre clé privée « maître », vous en dériveriez une nouvelle et de celle-ci vous généreriez la clé publique qui génère finalement l’adresse, puis lorsque cette adresse passe n’importe quel UTXO et indique par conséquent sa clé publique au réseau, un attaquant ne pourrait obtenir que la clé privée dérivée, mais jamais la clé « maître », ce qui signifie qu’au final l’utilisateur est relativement en sécurité tant qu’il ne réutilise pas la même adresse et continue à en générer une adresse chaque fois qu’ils veulent recevoir un UTXO.

Oui et non.

  • Les clés privées principales qui génèrent de manière déterministe les clés d’adresse réelles sont utilisées de manière omniprésente dans Bitcoin, précisément parce qu’elles permettent d’utiliser une nouvelle adresse pour chaque transaction sans avoir besoin d’une sauvegarde de chaque clé individuelle. La raison n’est pas la sécurité, mais la confidentialité cependant; la réutilisation des adresses révèle gratuitement des informations sur la propriété partagée des UTXO sur la chaîne
  • En théorie, il existe des mécanismes de dérivation de clé qui sont quantiques (ou pourraient l’être), en ce sens qu’un attaquant qui apprend (par quelque moyen que ce soit) la clé privée d’une adresse ne peut pas apprendre la clé principale à partir de laquelle elle a été générée. Le mécanisme de dérivation de clé commun utilisé dans Bitcoin (BIP32) n’utilise cependant pas de telles techniques, car il est incompatible avec xpubs. La méthode BIP32 (non renforcée) prend en charge le partage d’une clé publique principale avec une autre partie (correspondant à votre clé privée principale qui n’est jamais révélée), de manière à ce que ces autres parties puissent dériver les clés publiques correspondant aux clés privées que vous allez dériver. Cela permet aux portefeuilles de surveillance uniquement qui peuvent suivre les fonds sur une machine en ligne, tandis que les clés privées restent en sécurité sur une machine hors ligne
  • Tous les arguments ci-dessus s’appliquent toujours  : même si les attaquants ne peuvent pas calculer la clé privée principale à partir d’une clé privée d’adresse, cela ne les empêche pas de calculer les clés privées d’adresse à partir de clés publiques

qui fait l’objet de recherches très actives. Personnellement, je pense qu’il est trop tôt pour pousser cela dans la pratique, car les schémas existants aujourd’hui sont très nouveaux, sont encore souvent cassés et présentent d’énormes inconvénients (principalement la taille des clés ou des signatures), mais étant donné la rapidité avec laquelle le domaine progresse, je ‘ Je suis convaincu que ces préoccupations diminueront avec le temps.