使用現有密鑰生成的簽名生成密鑰對
我已經建構了一個應用程序，其中每個使用者都有一個私鑰/公鑰對，我想為他們生成第二個，但是我無法將第二個私鑰儲存在任何地方。
與隨機生成第二個私鑰相比，從第一個簽名的靜態資訊中確定性地生成第二個私鑰有什麼缺點？每次使用者打開應用程序時，我都可以再次生成它，但它安全嗎？
這是在乙太坊上使用確定性 ECDSA 的 Web 應用程序的上下文中。
將派生的私鑰/公鑰對生成為（或從）使用主私鑰計算的簽名的提議存在幾個問題。
- 並非所有簽名方案都是確定性的，因此所提議的最終可能不允許派生密鑰的複制。
- 我們需要區分用於生成派生密鑰的簽名方案的特定消息輸入，並確保攻擊者無法使用主密鑰獲得該消息的簽名，從而破壞派生密鑰的機密性。
- 對於任意簽名方案，我們可以想像一些安全問題，其中使用主密鑰的簽名（過去和未來）會削弱使用派生密鑰的簽名。
更保守的選擇是使用主私鑰本身作為對稱密鑰派生函式（與簽名方案無關）的密鑰輸入，該輸出是（或用於確定性地生成）派生密鑰。這可以推廣到任意數量的派生鍵，使用 KDF 的輔助輸入作為派生鍵類型或索引。該選項假定主私鑰不在盒子/HSM/智能卡/飛地中，限制其用於簽名，並且具有相同效果的嚴格策略無效（這很常見，例如參考 FIPS 186 -4)。
更新：評論提到無法直接訪問主私鑰（使上述保守選項成為不可能）；和確定性（變體）ECDSA。
如果我們可以保留消息 $ C_D $ （解決2.），後處理為$$ \text{DK}\gets(H(\text{Sign}_\text{MK}(C_D))\bmod(n–1))+1 $$似乎是派生私鑰的好方法 $ \text{DK} $ 從主私鑰 $ \text{MK} $ ， 和 $ n $ 生成器的順序和 $ H $ 至少 64 位寬的散列 $ n $ 是。模組化縮減和 64 位限制符合 FIPS 186-4 附錄 B.4.1。如果 $ H $ 在隨機 Oracle 模型中是安全的，並且與簽名驗證一樣昂貴，那麼這在計算上是安全的（論點：攻擊允許偽造 $ C_D $ ，或以其他方式破壞簽名方案或散列）。它只能幫助使用故意慢的 KDF $ H $ .
上述公式假設 ECDSA 僅將簽名 TRNG 更改為由私鑰加密的確定性 PRF。對於 EdDSA，我們只需要對保留消息的簽名進行雜湊處理 $ C_D $ 到私鑰的寬度，並以 EdDSA 中規定的遮罩為條件。
更一般地說，使用確定性簽名方案、保留消息和使用獨立於簽名方案的 KDF 的密鑰生成過程，並且至少與簽名驗證一樣昂貴，我們很高興。
警告：任何密鑰派生都應在安全的環境中執行，或者以其他方式防止側通道。