Soweit ich weiß, wird der Wallet Seed erstellt, indem in PBKDF2 (unter Verwendung von HMAC-SHA512, von dem 2048 Runden angewendet werden) eine Reihe von mnemonischen Codewörtern und ein optionales Salt (standardmäßig "mnemonic") eingegeben werden. Dies erzeugt einen 512-Bit-Seed, der für Brute-Force völlig unpraktisch ist. Dies ist ein Bild des Prozesses, auf den ich mich beziehe, aus Mastering Bitcoin. Warum wird es dann erneut mit HMAC-SHA512 gehasht, außer zum Erstellen von 512-Bit-Ausgabe (in dem Fall, in dem es ursprünglich 128 oder 256 gewesen sein könnte)? Warum nicht einfach nur einen SHA512-Hash verwenden (vorausgesetzt, der Grund besteht darin, nur 512 Bit zu erstellen)? Was ist der Sinn des HMAC hier? Längenerweiterungsangriffe aus den vorherigen Iterationen während PBKDF2 hätten vermieden werden sollen, oder?
Dies liegt daran, dass der Root-Seed möglicherweise nicht 512 Bit beträgt, sondern beispielsweise 128 Bit oder 256 Bit, wie in dem von Ihnen verlinkten Bild zu sehen ist. Somit wird der endgültige SHA-512 auf den Seed angewendet, sodass unabhängig vom Seed immer 512 Bits generiert werden.
Die in BIP 39 beschriebene Seed-Generierung ist unabhängig vom Schritt Seed -> erweiterter privater Schlüssel in BIP 32. Ich gehe davon aus, dass BIP 32 HMAC-SHA-512 anstelle von nur SHA-512 verwendet, da es keine Annahmen darüber trifft, wie der Seed generiert wurde. und möchte sicherstellen, dass der erweiterte private Schlüssel eindeutig für die Verwendung von BIP 32 generiert wird, anstatt nur irgendeinen alten SHA-512-Hash zu verwenden, der von woanders stammen könnte.
Leeren
meshcollider
Leeren
meshcollider