乙太坊賬戶的公鑰和私鑰的位置

我想知道有關 Parity 中密鑰生成和處理的詳細資訊。列出的問題都是相關的，所以我把它們都放在了這個問題文章中。

在 Parity 上創建新的乙太坊帳戶時，會在.../ethcore/<node-name>/keys/<chain-name>. 例如，這樣一個文件的內容是：

{
   "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":"{}"
}

看起來 KDF 是 PBKDF2，即基於密碼的 KDF。我猜帳戶密碼是用來派生密鑰和參數的"kdfparams"。

因此，我正在尋找以下問題的答案：

1. 是否在提供密碼時按需使用此 KDF 和給定的參數值派生私鑰？
2. 什麼是公鑰，或者它是如何生成的？不需要密碼。
3. "ciphertext"加密的純文字是什麼？
4. 該文件生成並保存在 Parity 節點上。這是否意味著私鑰並不完全且完全掌握在帳戶所有者的手中？

感謝您對這個問題有所了解。

評論中的一些連結幫助我得到了問題的答案。我從Coursera Cryptography-I 課程中收集了所有這些資訊以及我自己（最近獲得的）密碼學知識（對於問題 3 的答案）。

A1。私鑰永遠不會（或永遠不應該）未加密地保存在磁碟上。它是在使用者輸入密碼時從密鑰庫文件中的資訊生成的。

**A2。**公鑰可以從私鑰生成。但是，其他方（沒有私鑰）需要驗證此帳戶的簽名。這些各方將從簽名中獲取它，如下所述：獲取任何乙太坊帳戶的公鑰然後，簽名者的地址是公鑰的 Keccak-256 散列的最後 20 個字節。據推測，這應該與from:交易的地址相匹配。

**A3。**這是關於私鑰的 JSON 表示的結構和含義的（有點長）答案：

我從 wiki 頁面獲得了很多此類資訊：https ://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition並添加了一些我自己的資訊以使其更全面。

解密私鑰的所有資訊都在crypto元素中。該cipher元素標識用於加密私鑰的對稱加密方案。在給定的範例中，該方案是aes-128-ctr高級加密標準 ( aes) 分組密碼，其密鑰長度為128計數器 ( ctr) 操作模式中的位。旁白：另一種操作模式是密碼塊連結（CBC）。cipherparams包含加密中使用的任何參數的值。對於 AES-128-CTR，只有一個參數iv（初始化向量）。ciphertext是加密的私鑰。

要解密私鑰ciphertext，我們需要上述值。我們還需要對稱加密密鑰，用於加密私鑰。加密密鑰也不會以純文字形式顯示。它需要使用指定的密鑰派生函式 ( kdf) 使用指定的 KDF 需要的參數值( ) 進行派生kdfparams。給定範例中的 KDF 是pbkdf2- 基於密碼的 KDF。的參數pbkdf2是密碼（由使用者輸入）、偽隨機散列函式（prf）（例如，它是 HMAC-SHA256 hmac-sha256）、鹽值（salt）、迭代計數（c）和派生密鑰長度(dklen) 以字節為單位。密鑰是通過連接密碼和鹽值，並應用散列函式c次數得出的。這樣做是因為人類選擇的密碼沒有足夠的熵。為了防止這種情況，使用隨機鹽值和慢散列函式。（迭代次數是為了使散列函式變慢。它不會使密鑰派生變得更安全（正如一些人認為的那樣）。它只會使其花費更長的時間，從而使蠻力攻擊更加困難。）

導出加密密鑰後，使用 MAC 值 ( mac) 對其進行驗證。第二個 128 位（16 字節）塊與該ciphertext值連接。結果字節數組的 Keccak-256 雜湊值應等於該mac值。

如果加密密鑰通過驗證，則ciphertext使用指定的解密函式對 進行解密，並使用 中cipher給出的參數值cipherparams。此解密的結果是純文字私鑰。

**A4。**後來才知道，新賬號只能在自己控制的節點上創建。這就是personal預設情況下在 IPC 上啟用 API 而不是在 RPC 上啟用 API 的原因，以防止遠端節點接受新帳戶創建請求。

引用自：https://ethereum.stackexchange.com/questions/15494