Ich möchte die Details zur Schlüsselgenerierung und -handhabung in Parity erfahren. Die aufgelisteten Fragen hängen alle zusammen, also habe ich sie alle in diesen einen Fragepost gestellt.
Wenn ein neues Ethereum-Konto auf Parity erstellt wird, wird eine neue Datei unter .../ethcore/<node-name>/keys/<chain-name>. Der Inhalt einer solchen Datei ist beispielsweise:
{
"id":"eca798d8-8e68-a096-a35f-174133f86e43",
"version":3,
"crypto":
{
"cipher":"aes-128-ctr",
"cipherparams": { "iv":"45092c0a2032250e66a9d0bd2a33acaa" },
"ciphertext":"0385fd52dfc528713d7b0b72073b992b93aa78f32b0576848a9de69d6e836c3d",
"kdf":"pbkdf2",
"kdfparams":
{
"c":10240,
"dklen":32,
"prf":"hmac-sha256",
"salt":"e04e80b6174ca47c86e9174fd952949e53c900852d5c3cb62b863c5241e54f28"
},
"mac":"178d2c012e1970b853e1551fa9bb0a51b86955cc4ed8db53a9b60cbbdbca8c7b"
},
"address":"00faf16e4909296f5cca76e1ccd7cd811fba93d0",
"name":"User-007",
"meta":"{}"
}
Sieht so aus, als wäre das KDF PBKDF2, dh passwortbasiertes KDF. Ich denke, das Kontopasswort wird verwendet, um die Schlüssel abzuleiten, und die Parameter dafür sind in angegeben "kdfparams".
Daher suche ich Antworten auf folgende Fragen:
"ciphertext"der verschlüsselt wird?Danke, dass Sie etwas Licht in dieses Thema geworfen haben.
Einige der Links in den Kommentaren haben mir geholfen, Antworten auf meine Fragen zu bekommen. Ich habe all diese Informationen in Kombination mit meinen eigenen (kürzlich erworbenen) Kenntnissen über Kryptographie aus dem Coursera Cryptography-I-Kurs gesammelt (für die Antwort auf Frage Nummer 3).
A1. Der private Schlüssel wird niemals (oder sollte niemals) unverschlüsselt auf der Festplatte gespeichert werden. Es wird aus den Informationen in der Keystore-Datei generiert, wenn der Benutzer das Passwort eingibt.
A2. Der öffentliche Schlüssel kann aus dem privaten Schlüssel generiert werden. Es wird jedoch von anderen Parteien (die nicht über den privaten Schlüssel verfügen) benötigt, um Signaturen von diesem Konto zu verifizieren. Diese Parteien würden es aus einer Signatur ableiten, wie hier erklärt: Holen Sie sich den öffentlichen Schlüssel eines beliebigen Ethereum-Kontos . Dann sind die letzten 20 Bytes des Keccak-256-Hashes des öffentlichen Schlüssels die Adresse des Unterzeichners. Vermutlich sollte das mit der from:Adresse der Transaktion übereinstimmen.
A3. Hier ist eine (etwas lange) Antwort über die Struktur und Bedeutung der JSON-Darstellung des privaten Schlüssels:
Ich habe viele dieser Informationen von der Wiki-Seite: https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition und einige meiner eigenen hinzugefügt, um sie umfassender zu machen.
Alle Informationen zum Entschlüsseln des privaten Schlüssels befinden sich im cryptoElement. Das cipherElement identifiziert das symmetrische Verschlüsselungsschema, das zum Verschlüsseln des privaten Schlüssels verwendet wird. In dem gegebenen Beispiel ist das Schema aes-128-ctr, die Blockchiffre des Advanced Encryption Standard ( aes) mit einer Schlüssellänge von Bits im Betriebsmodus des 128Zählers ( ). Beiseite: Die andere Betriebsart ist Cipher Block Chaining (CBC) . enthält die Werte aller Parameter, die bei der Verschlüsselung verwendet werden. Für AES-128-CTR gibt es nur einen Parameter (Initialisierungsvektor). ist der verschlüsselte private Schlüssel.ctrcipherparamsivciphertext
Um die des privaten Schlüssels zu entschlüsseln ciphertext, benötigen wir die oben genannten Werte. Wir benötigen auch den symmetrischen Verschlüsselungsschlüssel, der zum Verschlüsseln des privaten Schlüssels verwendet wurde. Der Verschlüsselungsschlüssel wird auch nicht im Klartext angezeigt. Es muss mithilfe der angegebenen Schlüsselableitungsfunktion ( kdf) unter Verwendung der Werte der Parameter abgeleitet werden, die das angegebene KDF benötigt ( kdfparams). Das KDF im gegebenen Beispiel ist pbkdf2- ein passwortbasiertes KDF. Die Parameter für pbkdf2sind das Passwort (vom Benutzer einzugeben), eine pseudozufällige Hash-Funktion ( prf) (z. B. HMAC-SHA256 hmac-sha256), ein Salt-Wert ( salt), ein Iterationszähler ( c) und die abgeleitete Schlüssellänge (dklen) in Byte. Der Schlüssel wird abgeleitet, indem die Verkettung der Passwort- und Salt-Werte genommen und die Hash-Funktionszeiten angewendet werden c. Dies geschieht, weil von Menschen gewählte Passwörter keine ausreichende Entropie haben. Um sich dagegen zu wehren, wird ein zufälliger Salzwert und auch eine langsame Hash-Funktion verwendet. (Die Anzahl der Iterationen soll die Hash-Funktion langsamer machen. Sie macht die Schlüsselableitung nicht sicherer (wie einige glauben). Sie verlängert sie nur, um Brute-Force-Angriffe zu erschweren.)
Nach dem Ableiten des Verschlüsselungsschlüssels wird dieser anhand des MAC-Werts ( mac) verifiziert. Der zweite Block von 128 Bits (16 Bytes) wird mit dem ciphertextWert verkettet. Der Keccak-256-Hash des resultierenden Byte-Arrays sollte gleich dem macWert sein.
Wenn der Verschlüsselungsschlüssel die Überprüfung besteht, wird er zum Entschlüsseln der verwendet ciphertext, wobei die Entschlüsselungsfunktion der angegebenen ciphermit den in angegebenen Parameterwerten verwendet wird cipherparams. Das Ergebnis dieser Entschlüsselung ist der private Schlüssel im Klartext.
A4. Später wurde mir klar, dass ein neues Konto nur auf einem selbst kontrollierten Knoten erstellt werden sollte. Aus diesem Grund ist die personalAPI standardmäßig auf IPC, aber nicht auf RPC aktiviert, um zu verhindern, dass eine Anforderung zur Erstellung eines neuen Kontos von einem Remote-Knoten akzeptiert wird.
ciphertextverschlüsselt werden sollen. Aus Q.1 können Sie sehen, dass ich vermutet habe, dass das KDF seine Parameter und das Passwort verwendet, um den privaten Schlüssel abzuleiten. Also, was ist der Zweck von ciphertext? Welche Daten soll es darstellen? Die Informationen in meiner Antwort waren genau das, wonach ich gesucht habe, als ich diese Fragen gestellt habe. Meine Frage, meine Antwort.
eth
q9f
Ajoy Bhatia
personal.newAccountFromPhraseoder eine andere) aufgerufen wird. Das bedeutet also, dass man den Parity-Client (oder einen beliebigen Ethereum-Client) auf einem Knoten ausführen sollte, den man kontrolliert, und die Kontoerstellungsoperation darauf aufruft. Ist das richtig? dh ich sollte kein Konto erstellen, indem ich die API eines Remote-Knotens aufrufe, der sich nicht in meiner Kontrolle befindet?Jeff
personalEin entfernter (RPC-)Knoten wird die API wahrscheinlich sowieso nicht zulassen , es sei denn, er gibt dies mit an--rpcapi. Sie sollten Ihre private Schlüsseldatei nur auf Ihrem Computer generieren. Es ist auch möglich, es zu entschlüsseln und Ihren privaten Rohschlüssel zu erhalten, siehe hier .Ajoy Bhatia
eth