Was wäre eine vernünftige Unterschlüsseltiefe, die verwendet werden sollte, damit meine Adresse nicht über eine systematische Suche gefunden werden kann?

Pycoin verwenden.

ku <ext_pri_key> -s 1/4/6/2/8/4/2/5.......

Wie viele Ebenen tief in den Baum müsste ich gehen (nur mit einzelnen Ziffern), bevor es für einen Angreifer unmöglich wäre, ihn mit einer systematischen Suche zu finden.

Zwanzig Ebenen tief, dachte ich, wäre angemessen:

10**20 = 100000000000000000000

Ich weiß, dass es effektivere Möglichkeiten gibt, Ihre Adresse zu verschleiern, aber ich interessiere mich für diesen speziellen Anwendungsfall.

Vielen Dank.

Antworten (2)

Es ist etwas seltsam, einzelne Ziffern für den gesamten HD-Pfad zu verwenden, da die BIP32-Spezifikation Ihnen erlaubt, Zahlen bis zu 2^31 (nicht gehärtet) auszuwählen. Die BIP32-Schlüsselableitung verwendet weitgehend SHA512. Aktuelle ASICS für SHA256 können etwa 10 Billionen SHA256 pro Sekunde berechnen, also etwa 160 Trillionen Hash-Operationen in etwa 6 Monaten. Angenommen, ein ASIC kann mit ungefähr der gleichen Hash-Leistung gebaut werden, müssten Sie etwa 20 Ebenen tief gehen, um eine solche Maschine zu zwingen, Ihre Adresse in etwa 6 Monaten zu finden. Mehr Maschinen bedeuten natürlich schnelleres Knacken.

Eine viel einfachere Lösung wäre, den gesamten Platz jeder Ebene zu nutzen, anstatt nur 10. 3 Ebenen wären dann ausreichend (~ 10 ^ 28).

20 einstellige Ebenen entsprechen etwa log(10^20)/log(2) = etwa 66 Bit Entropie. Das erscheint mir viel zu niedrig.
Es wird wahrscheinlich zukünftige Optimierungen geben. Meine Berechnungen basieren auf aktueller Hardware und dass SHA512 zufällig genug ist.
Das Bitcoin-Netzwerk als Ganzes macht mehr als 2^66 Hashes pro Minute. Sicher, Hashing ist keine EC-Operation und die vorhandene Hashing-Hardware kann nicht dafür verwendet werden. Aber Sie schützen nicht vor einem bekannten Angreifer. Sie möchten sicher sein, dass derzeit oder in naher Zukunft niemand Ihre Schlüssel knacken kann. Da Operationen dieser Größenordnung bereits jede Minute stattfinden, sollten Sie wirklich nach einer viel größeren Sicherheitsmarge suchen. 2^128 ist heutzutage normalerweise die Mindestempfehlung.
Ich stimme zu. Und wenn der Angreifer die gesamte Ausrüstung des Bitcoin-Netzwerks hätte, wäre das sicherlich nicht sicher. Ich habe gesagt "mehr Maschinen bedeuten schnelleres Knacken". Dies sollte keine zukunftssichere Antwort sein, sondern nur eine Schätzung basierend auf aktuellen Hash-Raten und einem einigermaßen kostengünstigen Crack.

Wenn Sie einen zufälligen Schlüssel von einem anderen ableiten müssen (und nicht von einem, der durch iterative Suche gefunden werden kann), verwenden Sie BIP32 nicht.

Wenn Sie eine normale Ableitung wünschen (wobei die Pubkeys abgeleitet werden können, ohne den übergeordneten Privatschlüssel zu kennen), verwenden Sie das Pay-to-Contract-Schema: privkey = parent_privkey + H(parent_pubkey || id) pubkey = parent_pubkey + H(parent_pubkey || id) * G

Wenn Sie eine härtere Ableitung wünschen, verwenden Sie einfach den übergeordneten Schlüssel als zusätzliche Entropiequelle: privkey = H(parent_privkey || id) pubkey = H(parent_privkey || id) * G

(wobei id mindestens 16 Byte Zufälligkeit ist)

BIP32 kann verwendet werden, wenn Sie es wirklich brauchen, für diesen Anwendungsfall, aber es ist unnötig kompliziert. Ich würde nicht weniger als 5 Ebenen von 31-Bit-Ganzzahlen (4 wären weniger als 128 Bit Entropie) oder nicht weniger als 39 Ebenen für einstellige Unterpfade (129,55 Bit Entropie) vorschlagen.

Anscheinend wäre es zufälliger, wenn ich ein Bild von dir als Entropie verwenden würde, um einen Zufallsschlüssel zu generieren, als wenn ich irgendein anderes Bild verwendet hätte;)