RFC 6979 - 為什麼不簡單地散列消息和確定性 ECDSA 的私鑰？

為什麼要麻煩使用 HMAC_DRBG 過程，而不是簡單地散列[message | private key]來計算 $ k $ 對於確定性 ECDSA？

如果結果 $ k $ 或者簽名無效，則可以將一個已知的字節值附加到輸入中，並重新散列，直到獲得可接受的結果： k=h([message|privateKey|0x00 … 0x00])

與所需的迭代次數一樣多0x00的字節。

我在這裡錯過了一個固有的弱點嗎？

編輯：如果散列函式輸出長度小於曲線順序，則可以根據需要連接多個散列輸出（通過附加已知字節產生，類似於上述內容）： k=[ h([message|privateKey]) | h([message|privateKey|0x00]) ... ] 一旦有足夠的輸出，就可以截斷它以匹配曲線順序位長度。

如果結果 $ k $ 或者簽名不好，然後用附加的已知字節重新啟動： k=[ h([message|privateKey|0x00]) | h([message|privateKey|0x00 0x00]) ... ]

以此類推，直到可以接受 $ k $ 被生產。

確定性簽名在隨機預言機模型中是安全的。使用 HMAC_DRBG 使我能夠依賴現有的關於該結構的安全性以及它與“真正的”隨機預言的接近程度的研究。如果我使用任何其他“手工”結構，那麼我將不得不提供廣泛的分析，說明它為什麼是安全的。天生懶惰，我選擇了HMAC_DRBG。

此外，HMAC_DRBG 的這種使用使最終結果更加“令人信服”——將加密算法指定為 RFC的很大一部分是為了讓其他人使用它。

（如果我當時知道它的存在，我可能會考慮使用HKDF而不是 HMAC_DRBG，但這在實踐中並不重要。）

引用自：https://crypto.stackexchange.com/questions/20538