PublicKey Ƀ vs. Ethereum

[block847383]

Moin, der Neue hier gleich mit einer Frage

(Historisch gewachsen) besitze ich einen Ledger als HODL-Wallet. Vor einiger Zeit habe ich (via Ledger) die restlichen ETH für BTC umgetauscht. Soweit so gut. Wichtig an der Stelle ist die Tatsache, dass sowohl der BTC- wie auch der ETH-Account via Ledger verwaltet werden.

Nun weiter...

Später kam mir ein Artikel in die Hände, wo empfohlen wurde, aus HODL-Wallets keinerlei Transaktionen zu machen, um den PublicKey nicht öffentlich zu machen (könnte irgendwann in der Zukunft zurückgerechnet werden). Ausgehende BTC-Txs gab es bis dato nicht, nur die eine ETH-Tx.

Jetzt ist die Frage, sind Ethereum-PublicKeys identisch zu Ƀ? Also hab ich durch meine ausgehende ETH-Überweisung auch den BTC-PublicKey offen gelegt? Wäre sehr schade drum.

Danke euch für die Hilfestellung.

[Lakai01]

Erstmal herzlich willkommen im Forum!

Jetzt ist die Frage, sind Ethereum-PublicKeys identisch zu Ƀ? Also hab ich durch meine ausgehende ETH-Überweisung auch den BTC-PublicKey offen gelegt? Wäre sehr schade drum.

Technisch sind die Public Keys von ETH und BTC ident, ja. Die nutzen beide secp256k1:

Secp256k1 is an elliptic curve used primarily in the context of cryptographic algorithms and is most famously associated with Bitcoin and other cryptocurrencies

Quelle

Dadurch können die gleichen Public/Private Keys sowohl in BTC als auch in ETH verwendet werden. Nachdem du also mit deinem Mnemonic Code vom Ledger sowohl dein ETH-Wallet als auch dein BTC-Wallet wiederherstellen kannst gehe ich davon aus, dass du den jetzt offengelegt hast, ja.

[block847383]

Ich danke dir vielmals für deine Antwort.

[block847383]

Ich möchte natürlich nicht in Panik verfallen und Assets auf eine neue Wallet verschieben, daher frage ich euch, wann es eurer Meinung nach soweit sein wird, dass PublicKeys der NativeSegwit Adressen zurückgerechnet werden können?

Wenn ich das richtig verstanden habe, können die alten 1er-Adressen anhand eines PublicKeys ermittelt werden. So suggeriert zumindest diese Beschreibung, sollte man das Puzzle66 lösen:

Once Puzzle 66 is found and the prize is transferred to another address, the bots come into play and capture the relevant transfer transaction. Since the "public key" of the relevant puzzle will be revealed in this transfer process, can one quickly find the private key of the relevant puzzle with the previously mentioned methods (probably less than 1 minute) and manipulate the transaction? Of course, there are risks, but it is up to you to minimize them.

Quelle

[HeRetiK]

Die Puzzle-Transaktionen sind explizit so gemacht dass sie im Vergleich zu herkömmlichen Transaktionen leichter zu lösen sind. Bis aus den Public Keys von richtigen Transaktionen der Private Key abgeleitet werden kann, hast du noch paar Jährchen wenn nicht Jahrzehntchen Zeit, je nachdem wie die Entwicklung von Quantencomputern voranschreitet.


Als Referenz, dieses Paper von 2022 geht davon aus das 13 × 10^6 physische Qubits benötigt würden um den Private Key eines secp256k1 Public Keys innerhalb eines Tages abzuleiten:

it can be seen that it would require 317 × 10^6 physical qubits to break the encryption within one hour with a code cycle time of 1 μs. To break it within 10 min with the same code cycle time, it would require 1.9 × 10^9 physical qubits, whereas to break it within 1 day, it would require only 13 × 10^6 physical qubits.

Leider gibt es kein Szenario in dem sie dem Angreifer etwas mehr Zeit lassen, aber wir dürften uns in einer Größenordnung bewegen wo 10^5 physische Qubits benötigt werden um einen einzelnen Private Key innerhalb eines Jahres abzuleiten.


Das höchste der Gefühle sind derzeit 10^3 Qubits:
https://www.newscientist.com/article/2399246-record-breaking-quantum-computer-has-more-than-1000-qubits/


Google selber geht davon aus erst 2025 bei 10^3 physischen Qubits anzukommen:
https://quantumai.google/

Es sei angemerkt dass sich selbst Google für alles ab 10^4 physischer Qubits noch keine Jahresangaben machen traut.


IBM schätzt ab 2030+ bei 10^5 anzukommen:
https://www.ibm.com/roadmaps/quantum.pdf


Also a bisserl Zeit ist noch.

Sollten die Entwicklungen doch schneller voranschreiten als die bisherigen vermutlich sehr optimistischen Annahmen von Google und Co, sollte es genug Vorlaufzeit geben um die coins in ein frisches Wallet zu transferieren.

[block847383]

Vielen Dank für die Erklärung!

[d5000]

Jetzt ist die Frage, sind Ethereum-PublicKeys identisch zu Ƀ? Also hab ich durch meine ausgehende ETH-Überweisung auch den BTC-PublicKey offen gelegt? Wäre sehr schade drum.

Ich glaube du kannst dich mit 99,9% Wahrscheinlichkeit hier beruhigt zurücklehnen (und widerspreche hiermit Lakai01, sorry ).

Du fragst ja, ob du durch die ETH-Überweisung den BTC-PublicKey offenlegst. So wie ich das verstanden habe, hast du alle ETH in Bitcoin umgetauscht und dann an deine Ledger-BTC-Addresse gesendet.

Durch die ETH-Überweisung legst du meines Wissens nach aber nur den ETH-Publickey offen, nicht den BTC-Key. Und das ist ja egal, die ETH sind ja nicht mehr in deinem Besitz.

Dass der gleiche Mnemonic Code genutzt wird, sollte da nicht ins Gewicht fallen. Denn jeder Publickey ist ja direkt einem Privatekey zugeordnet. Der Mnemonic Code generiert dir mehrere Adressen und Schlüsselpaare. Diese bleiben aber unabhängig voneinander. Auch wenn du beispielsweise mehrere BTC-Adressen mit einem Mnemonic Code verwaltest, legst du nicht alle Publickeys offen, wenn du von einer davon Bitcoins versendest. Und bei Addressen verschiedener Coins (hier BTC und ETH) gilt das genauso. Auch dass beide Secp256k1 nutzen ist da egal.

Die 0,01% Restunsicherheit resultieren daraus, dass es theoretisch sein könnte, dass der Ledger irgendwie ganz anders funktioniert als andere HD-Wallets (ich bin kein Ledger-Experte) und man über irgendwelche Umwege doch aus einem ETH-Publickey den BTC-Publickey errechnen kann weil der Algorithmus ausgehend vom Mnemonic Code diese über irgendein einheitliches Verfahren generiert. Aber wenn ja, dann wäre das höchst fahrlässig von Ledger. Wenn das so sein sollte, wäre ich von @Lakai01 um eine Erklärung dankbar

Auch die Bitcoin-Überweisung (von der Exchange zu deiner Wallet) sollte unbedenklich sein: sie geht ja an die Adresse, aus der der Publickey nicht errechnet werden kann, also nicht an den Publickey (es sei denn, du hast P2PK statt P2(W)PKH genutzt, aber das macht eigentlich seit 2011 oder 2012 so gut wie niemand mehr ...).

[Lakai01]

Jetzt ist die Frage, sind Ethereum-PublicKeys identisch zu Ƀ? Also hab ich durch meine ausgehende ETH-Überweisung auch den BTC-PublicKey offen gelegt? Wäre sehr schade drum.

Ich glaube du kannst dich mit 99,9% Wahrscheinlichkeit hier beruhigt zurücklehnen (und widerspreche hiermit Lakai01, sorry ).

Absolut kein Problem, ich bin ja auch selber Schuld wenn ich meine Gedankengänge nicht sauber offen lege

Hintergrund meiner Aussage ist ganz einfach "better safe than sorry". Hier kommen 2 Punkte ins Spiel:

Punkt 1: Der von dir bereits angesprochene Punkt, dass man nicht weiß, wie Ledger hier die Private Keys genau generiert und/oder zuordnet, die legen das natürlich auch nicht offen.

Punkt 2:
Die Frage vom OP hat dann Relevanz, wenn der von HeRetik geschilderte Fall eingetreten ist: Es gibt Möglichkeiten, gängige Verschlüsselungsalgorithmen in annehmbarer Zeit zu brechen. Die Ableitung von Private Keys passiert bei HD Wallets ja sehr vereinfacht dargestellt so:


Quelle

Hier in dieser Grafik sieht es so aus, als ob zwischen Master Key und Private Key eine 1:1-Beziehung besteht, dem ist aber nicht so.
Der Master Key wird dazu genutzt ein Set von Private Keys zu generieren, wodurch OPs Befürchtungen grundsätzlich nicht eintreffen sollten. Im Fall der Verfügbarkeit von leistungsstarken Quantencomputern ist es aber technisch möglich, vom Public Key auf den Private Key und von dort auf den Master Key zu rechnen (nochmal: das ist derzeit NICHT möglich). Ist also ein Public Key bekannt so wäre automatisch der gesamte Master Key "verseucht". Da dieser für die Berechnung der Private Key-Paare aus dem Seed verwendet wird wäre es somit möglich, auch an die anderen Private Keys zu kommen, "hardened keys" hin oder her.


Die Überlegung ist derzeit wie gesagt noch fiktional, da weder derart starke Quantencomputer noch ein Weg existiert, um von einem Private Key auf den Master Key zurückzurechnen. Wenn das mal der Fall ist ist aber denke ich auch die Crypto-Entwicklung derart fortgeschritten, dass auch die dann verwendeten Algorithmen "quantensicher" sind.

Grundsätzlich bringt mich das aber zurück zur Frage des OPs: Man kann nicht ausschließen, dass durch die Verwendung auch der Bitcoin Private Key ermittelt werden kann. Auch wenn die Chance höchstwahrscheinlich eher gering (Ledger hat einen Flaw bei der Ermittlung) bzw. derzeit noch nicht relevant (keine derart leistungsstarken Quantencomputer verfügbar) ist.

[HeRetiK]

Ist also ein Public Key bekannt so wäre automatisch der gesamte Master Key "verseucht". Da dieser für die Berechnung der Private Key-Paare aus dem Seed verwendet wird wäre es somit möglich, auch an die anderen Private Keys zu kommen, "hardened keys" hin oder her.

Im Falle von hardened keys müsste der Master Key allerdings auch post-Quantum sicher bleiben, weil Quantencomputer gegenüber klassischen Computern keinen Vorteil beim "brechen" von SHA512 haben. Außer ich übersehe einen anderen Angriffsvektor?

[Lakai01]

Im Falle von hardened keys müsste der Master Key allerdings auch post-Quantum sicher bleiben, weil Quantencomputer gegenüber klassischen Computern keinen Vorteil beim "brechen" von SHA512 haben. Außer ich übersehe einen anderen Angriffsvektor?

Zusätzliche Angriffsvektor denke ich nicht, nein. Mit höheren Qubits wird aber auch die Anzahl an Bruteforce-Versuchen pro Sekunde immer höher, wofür SHA einfach "relativ anfällig" ist.

Wie gesagt das ist alles noch Theorie und das Brechen von sha512 ist vermutlich noch Jahrzehnte entfernt ... solange man natürlich darauf vertraut, dass bspw das Militär nicht bereits über deutlich stärkere Quantencomputer verfügt als bspw Google und IBM angeben. Das würde ich ebenfalls durchaus nicht ausschließen!

[HeRetiK]

Zusätzliche Angriffsvektor denke ich nicht, nein. Mit höheren Qubits wird aber auch die Anzahl an Bruteforce-Versuchen pro Sekunde immer höher, wofür SHA einfach "relativ anfällig" ist.

...nicht wirklich? Im Gegensatz zu ECC oder AES fällt SHA2 nicht in die Kategorie von kryptographischen Algorithmen die gegenüber Quantencomputern explizite Schwächen aufweisen (Shor-Algorithmus respektive Grover-Algorithmus). Bin jetzt allerdings auch nicht so tief in der Thematik drinnen.

Unterm Strich ist es vorerst eh egal, zumal sich sowieso die Frage stellt ob die Arbeit an Quantencomputern zu unseren Lebzeiten noch Früchte tragen wird. Die Hardware-Implementierung ist halt doch sehr komplex und die Use Cases wo Quantencomputer gegenüber klassischen Computern echte Vorteile haben erweisen sich derzeit noch als sehr eingeschränkt. Böse Zungen behaupten sogar dass das Haupteinsatzgebiet von Quantencomputern die Simulierung von Quantencomputern sein wird Aber es soll ja auch Leute gegeben haben die fest davon überzeugt waren das niemand einen Computer bei sich zuhause stehen haben wird oder dass das Internet sowieso nur eine Modeerscheinung ist.

[d5000]

Danke für die Erklärung Lakai01!

Im Fall der Verfügbarkeit von leistungsstarken Quantencomputern ist es aber technisch möglich, vom Public Key auf den Private Key und von dort auf den Master Key zu rechnen (nochmal: das ist derzeit NICHT möglich). Ist also ein Public Key bekannt so wäre automatisch der gesamte Master Key "verseucht". Da dieser für die Berechnung der Private Key-Paare aus dem Seed verwendet wird wäre es somit möglich, auch an die anderen Private Keys zu kommen, "hardened keys" hin oder her.

Ich denke, dieses Szenario wäre auch aus anderen Gründen "fiktional" als dass es heute noch nicht möglich ist.

Normalerweise denke ich mir wird ein Quantencomputer-Dieb so vorgehen: Adressen suchen, auf denen Coins liegen, und von denen selbst Public Keys veröffentlicht wurden, und dann die Privatekeys dazu errechnen. Das wird ja am Anfang durchaus einige Zeit benötigen.

Aber selbst wenn der QC für das "Knacken" einer Bitcoinaddresse und auch für die Masterkey-Errechnung nur noch eine Minute braucht, müsste für dieses Szenario dem Quantencomputer-Dieb bekannt sein, welche Schlüsselpaare zu einer HD wallet gehören. Es gäbe dabei zwei Vorgehensweisen:

- der QC-Dieb macht "Brute Force": Er schaut alle Adressen durch, die irgendwann mal den Public Key preisgegeben haben, errechnet (in zwei Schritten) den Masterkey und leitet dann von jedem Masterkey die Millionen Schlüssel ab, die von einem einzigen Masterkey generierbar sind, und schaut all diese durch, ob dort eine Balance besteht. Er müsste im Fall des OP dann auch noch dasselbe für mehrere relevante Blockchains wiederholen.

- der QC-Dieb macht Chainanalyse. Er könnte beispielsweise die Adressen kennen, die Ledger für den Umtauschvorgang benutzt, und so durch das "Matching" von jeweils zwei Transaktionen ähnlicher Beträge die BTC- zu ETH-Adressen zuordnen. Dafür müsste er aber ebenfalls viele mögliche Kombinationen durchprobieren.

Beide Verfahren scheinen mir möglich, aber so aufwändig, dass es sich wohl nur im Fall wirklich enormer Bitcoinmengen lohnen sollte. Er muss ja eine Menge Addressen "auf Verdacht hin" durchprobieren, ohne zu wissen, ob er Erfolg haben wird. Es ist jedenfalls weit mehr nötig als einfach nur zwei Quantencomputer-Operationen (Public->Private und dann Private->Master). Jedenfalls erwarte ich solche Diebstähle über mehrere Ecken erst dann, wenn selbst die Bildzeitung schon über die gecrackten Adressen berichtet hat.

Also grundsätzlich bleibe ich beim Standpunkt: das wird so zu 99.9%+ nicht passieren. Und ich denke auch im OP wurde die Frage gestellt, ob man mit dem ETH-Publickey den BTC-Publickey preisgibt. Direkt stimmt das jedenfalls nicht - nur wenn ein Angreifer die oben beschriebene Strategie anwendet.

Dazu kommt ja, wie von HeRetiK erwähnt, dass zumindest laut BIP32 SHA-512 (ein Hashing-Algorithmus also) beim Generieren von Childkeys verwendet wird und somit Shors Algorithmus nicht für diesen Schritt anwendbar ist. Es ist also wie schon in eurer Diskussion gesagt mindestens ein Schritt nötig, bei dem Quantencomputer keinen Vorteil bringen.