Electrum 2-Validierung: Wie ist der HMAC immer 01 ...?

Electrum Version 2 erstellt aus einer Zufallszahl einen Seed, der dann als Mnemonik kodiert wird. Der Seed wird validiert, indem überprüft wird, ob der hmac mit den Bytes 01oder 101für Standard- bzw. 2fa-Typen beginnt.

Ich habe mir den Python-Code auf Github angesehen und er gibt tatsächlich das 01-Byte zurück, aber ich bin immer noch verwirrt darüber, wie man sicherstellen kann, dass ein Hash mit einem vorhergesagten Wert ( 01\101) beginnt.

Wie kann das sein? Fehlt mir die Nuance dessen, was der Code tut, oder das Konzept, wie hmac funktioniert?

Antworten (1)

Beim Erstellen eines neuen Seeds macht Electrum 2.x so ziemlich dasselbe wie Vanity-Adressgeneratoren oder Bitcoin-Miner, was das angeht … es „mahlt“.

Es generiert einen Seed basierend auf etwas Entropie und einer Nonce und prüft, ob der HMAC des Seeds mit der erforderlichen Bytesequenz (der "Prüfsumme") beginnt. Wenn dies nicht der Fall ist, erhöht es die Nonce und überprüft seinen HMAC erneut.

Wenn Sie interessiert sind, finden Sie den Code, der dies tut, hier auf GitHub .

Es sollte beachtet werden, dass Electrum-Seeds (standardmäßig) 128 Bit Entropie haben. Als Ergebnis dieses Schleifens verwirft Electrum (für Standard-Wallets mit einer Prüfsumme von 0x01) 255 von jeweils 256 potenziellen Seeds. Dadurch wird die Entropie in einem Seed effektiv um 8 Bit (die Länge der Prüfsumme) verringert. Um dies zu kompensieren, fügt Electrum 2.x der gesamten Seed-Länge weitere 8 Bit hinzu, was die Seed-Länge auf 136 Bit und die Entropie wieder auf 128 Bit bringt.

Beachten Sie, dass es erheblich schneller ist als die meisten Vanity-Generatoren, da es nur ~128 HMAC-SHA2-Operationen ausführen muss, was wirklich schnell ist.
Ah ha, deshalb wird die True-Schleife verwendet. Ich dachte, es würde nur einmal verwendet, da while old_seedes mir intuitiver erscheint. Ich kann die Begründung jetzt verstehen, insbesondere nachdem ich erfolgreich zahlreiche Fälle von Electrum 1-Seeds gefunden habe, die einen 01-Hmac zurückgaben. Ich bin neugierig ... ist es möglich, ein besseres System zu implementieren, bei dem ein alter Seed niemals als neuer Seed interpretiert werden kann, oder ist dies nur das geeignetste, da es sich um einen Hash-basierten Seed handelt?
@WizardOfOzzie Eine Idee, die Electrum implementieren könnte (aber noch nicht), ist, die Standard-BIP-39-Wortliste zu verwerfen und eine benutzerdefinierte zu verwenden, die keine gemeinsamen Wörter mit der Electrum 1.x-Liste hat. Electrum verzichtet bereits auf BIP-39 , also gibt es keinen Grund, dieselbe Wortliste beizubehalten. Die BIP-39-Wortlisten sind nicht einmal besonders gut – sie verstoßen gegen die eigene Empfehlung von BIP-39, keine ähnlichen Wörter zu verwenden (Auktion/Aktion, Bewegung/Emotion, Garage/Müll usw.).
@ChristopherGurnee Ich wollte gerade dieselbe Lösung ansprechen, nachdem ich den ganzen Tag darüber nachgedacht hatte. Es ist meiner Meinung nach sowohl programmatisch als auch intuitiv eine viel bessere Abgrenzung
@nickodell du hast recht. Ich habe es sicherheitshalber ausgeführt :) Wo wir gerade beim Thema sind, was ecdsa.utils.randrangebringt es, die Nonce auszuführen und zu erhöhen, wenn es genauso wahrscheinlich ist, dass das Ausführen der Schleife für eine Zufallszahl einen gültigen Startwert zurückgibt?
@WizardOfOzzie Keine Ahnung davon. Mir kam der gleiche Gedanke.
@nickodell Sha512 hmac übrigens. Interessanterweise, und das ist neu für mich, hat Python Hashlib eine pbkdf2_hmac-Funktion, die verdammt viel schneller ist als meine optimierte pbkdf2-Funktion
Electrum 2-Validierung: Wie ist der HMAC immer 01 ...?
AntwortenHierDatenschutz-Bestimmungen1y, 0v