Ich habe mir das jetzt auch endlich einmal durchgelesen und verstehe das folgendermaßen (wirklich nur mein Verständnis bzw. meine Interpretation; vielleicht falsch).
Alleine ein Child Private Key + Parent Chain Code reichen denke ich nicht aus, um den Parent Private Key zurückzurechnen. Dem Parent Chain Code wird man allerdings auch nicht alleinstehend begegnen, sondern nur als Teils des Parent Extended Public Keys (xpub).
Ich denke im Buch ist es so gemeint, dass ein Child Private Key + xpub ausreichen, um den Parent Private Key zu ermitteln. Der Parent Public Key alleine würde nicht reichen, aber der xpub beinhaltet eben zusätzlich den Parent Chain Code.
So ähnlich ist das zu Beginn des gleichen Absatzes im Buch geschrieben, und so steht es auch im BIP32:
Note however that the following properties does not exist:
- Given a parent extended public key (Kpar,cpar) and a child public key (Ki), it is hard to find i.
- Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.
Angenommen also man hat einen einzelnen Private Key, sowie den xpub einer fremden Wallet gefunden. Man hat demnach einen Child Private Key + Parent Public Key + Parent Chain Code.
Dann würde ich folgendermaßen vorgehen:
Normalerweise fangen die Wallets bei der Ableitung der Private Keys und Adressen beim Index 0 an.
Man probiert der Reihe nach alle Indices durch, angefangen bei Index = 0. Für jeden Index erzeugt man aus xpub und Index über die Child Key Derivation function (HMAC-SHA512) die „left 256 bits“.
Ein Child Private Key ist die Summe aus dem Parent Private Key und den „left 256 bits“ des jeweiligen Indexes. Das steht glaube ich nicht direkt im Buch, aber im BIP32.
Von dem geleakten Private Key subtrahiere ich also die „left 256 bits“ und erhalte einen Parent Private Key Kandidaten.
Aus diesem berechne ich über secp256k1 einen Parent Public Key. Falls dieser dem tatsächlichen Parent Public Key entspricht, habe ich den Parent Private Key und damit auch den Parent Extended Private Key (xpriv) gefunden. Falls nicht zähle ich den Index eins hoch und probiere weiter.
Gehärtete Keys:
Bei gehärteten Child Private Keys ist das nicht möglich, da diese nicht von Parent Private Key + Parent Extended Public Key (xpub) abgeleitet werden, sondern ausschließlich vom Parent Extended Private Key (xpriv).
Einschätzung:
Ist es ein Problem, dass bei Verlust von xpub und eines einzelnen Private Keys der Gesamtverlust eines Accounts droht? Man muss bedenken, dass man früher vor den Hierarchisch-Deterministischen Wallets entweder nur eine Adresse, oder einen Haufen unkorrelierter Adressen hatte.
Entweder hatte man also nur einen Private Key, was bei Verlust des Keys ebenfalls einen Komplettverlust der Wallet bedeutete. Dagegen ist es heute etwas sicherer, da man eben noch mindestens den xpub benötigt.
Oder man hatte viele unkorrelierte Adressen und Private Keys. Das war beim Portieren und Sichern von Wallets sehr unkomfortabel, scheint aber erst einmal sicherer als heute. Ich denke aber das ist ein Trugschluss, da man beim Sichern und Verwahren von so vielen Keys sicher leichter Fehler macht.
Ein Zwischenschritt, der im Vergleich am sichersten ist, sind die nicht-hierarchisch, aber deterministischen Wallets. Dort wird alles von einem Seed abgeleitet, aber es gibt keine xpubs. Diesen Spezialfall könnte man heute immer noch erreichen, wenn man ausschließlich gehärtete Keys verwenden würde.
Ich weiß nicht ob es Wallets gibt, wo man das bis zur untersten Ebene einstellen kann (Electrum?). Ich persönlich bräuchte z.B. keinen xpub.