Glossar / Adressen und Schlüssel
Gehärtete vs. nicht gehärtete Ableitung
- Was ist Gehärtete vs. nicht gehärtete Ableitung?
- Gehärtete und nicht gehärtete Ableitung teilen die Kind-Indizes von BIP-32 in zwei Hälften: Nicht gehärtete Kinder lassen sich aus einem erweiterten öffentlichen Schlüssel berechnen, gehärtete Kinder nicht.
Spezifiziert im BIP-32.
Die Härtung ist eine Grenze in Ihrem Ableitungspfad und keine Einstellung, die Sie umschalten. BIP-32 wurde am 11. Februar 2012 nur mit nicht gehärteter Ableitung vergeben; die private Ableitung für Indizes ab 0x80000000 wurde am 16. April 2013 ergänzt, und diese Schlüssel wurden am 15. Januar 2014 in gehärtet umbenannt. Wo diese Grenze liegt, entscheidet darüber, wie viel von Ihrer Wallet ein geteilter erweiterter öffentlicher Schlüssel preisgibt.
So funktioniert es
Die nicht gehärtete Ableitung hat eine Eigenschaft, die der gehärteten Ableitung bewusst fehlt, und BIP-32 hält den Unterschied als algebraische Identität fest. Schreiben Sie N() für die Neutrierung, den Schritt, der die private Hälfte eines erweiterten Schlüssels verwirft und den 32-Byte-Chain-Code behält. Über nicht gehärtete Ebenen hinweg ist N(m/a/b/c) gleich N(m)/a/b/c, sodass Neutrierung vor der Ableitung und Neutrierung nach der Ableitung beim selben Schlüssel landen. Auf einer gehärteten Ebene bricht diese Umformung: N(m/a') lässt sich nicht in N(m)/a' umwandeln, denn die öffentliche Ableitung ist nur für nicht gehärtete Kinder definiert und liefert für alles andere einen Fehler.
Mechanisch unterscheiden sich die beiden Modi in einem einzigen Feld. Beide verwenden den Chain-Code des Elternschlüssels als Schlüssel eines HMAC-SHA512 und hängen den 4-Byte-Index an. Der nicht gehärtete Modus liefert den komprimierten öffentlichen Schlüssel des Elternschlüssels; der gehärtete Modus liefert das Geheimnis des Elternschlüssels, das mit einem führenden Null-Byte auf dieselbe Breite von 33 Byte aufgefüllt wird. Nichts, das nur einen xpub besitzt, verfügt über diese zweite Eingabe, also endet die Ableitung an der Grenze.
BIP-32 ist ungewöhnlich deutlich darüber, was nicht gehärtete Schlüssel nicht schützen. Der Abschnitt zur Sicherheit führt zwei Eigenschaften als fehlend statt als vorhanden auf: Sind ein erweiterter öffentlicher Elternschlüssel und ein öffentlicher Kindschlüssel gegeben, ist das Auffinden des Index nicht schwer, und sind derselbe erweiterte öffentliche Elternschlüssel plus irgendein nicht gehärteter privater Kindschlüssel gegeben, ist auch die Wiederherstellung des erweiterten privaten Elternschlüssels nicht schwer. Das Erste kostet Sie Ihre Privatsphäre. Das Zweite kostet Sie den Zweig.
Wo Sie das sehen
Nicht gehärtete Ebenen sind der Grund, warum sich das Exportieren eines erweiterten öffentlichen Schlüssels lohnt, und BIP-32 widmet den darauf aufbauenden Weitergabevereinbarungen einen eigenen Abschnitt. Ein Prüfer, dem die erweiterten öffentlichen Schlüssel der Konten übergeben werden, sieht jede Zahlung in jedes Konto hinein und aus jedem Konto heraus und keinen einzigen geheimen Schlüssel. Zwei Firmen, die häufig handeln, können die externe Kette eines einzelnen Kontos als feste Zahlungsadresse teilen, sodass keine für jede Überweisung eine neue anfordern muss. Ein Webshop kann dieselbe Art von Schlüssel an seinen Webserver weitergeben, der dann Empfangsadressen erzeugt, über die er keine Verfügungsmacht hat.
Die Aufteilung, die die Grenze auf die Kontoebene legt, ist eine Empfehlung, keine Regel. BIP-32 bezeichnet seine Struktur aus Master, Konto, Kette und Unterkette als rein beratend und teilt den Implementierungen mit, dass sie für spezielle Anforderungen davon abweichen dürfen, weshalb eine konforme Wallet mehr Ebenen härten kann als die konforme Wallet daneben.
Eine Interoperabilitätsfalle ist es wert, gekannt zu werden, denn die Spezifikation wurde ihretwegen zweimal nachgebessert. Testvektoren für die gehärtete Ableitung mit führenden Nullen wurden am 24. Februar 2017 und erneut am 4. November 2020 ergänzt. Die gehärtete Eingabe hat eine feste Länge von 33 Byte, ein Null-Byte gefolgt vom 32-Byte-Geheimnis, sodass Software, die eine führende Null abschneidet statt diese Breite einzuhalten, andere Daten hasht, einen anderen Zweig erzeugt und eine leere Wallet vorfindet, wenn jemand diese Seed-Phrase in einem anderen Programm wiederherstellt. Die nicht gehärtete Ableitung trifft diesen Fehler nie, denn ein komprimierter öffentlicher Schlüssel beginnt immer mit 0x02 oder 0x03 und hat daher keine führende Null zu verlieren.