Schnorr-Signatures
k 選擇 Schnorr 簽名
所以我正在閱讀Schnorr 簽名的 BIP，但我找不到任何解釋為什麼沒有選擇簡單的RFC6979 變體作為他們的隨機數生成。相反，他們決定採用自己的實施方式。為什麼是這樣？
編輯：澄清我不是指正常的 RFC6979。
我不確定您指的是哪種簡化變體，但這是一個很好的問題。
有很多原因。
首先，RFC6979 並不便宜而且相當複雜。計算單個候選隨機數需要 22 次 SHA256 壓縮函式呼叫。散列很快，但這實際上對應於散列 1400 個字節，與簽名時間相比，這不再是微不足道的了。它有一個目的——它實例化了一個眾所周知的 PRNG 來生成候選隨機數——但這對我們來說太過分了。
secp256k1有一個有趣的屬性，它的組階幾乎可以忽略不計地接近2 256。因此，根本不需要 PRNG - 一個雜湊就足夠了，它的複雜性較低，而且顯然也是恆定的時間。一個更簡單的替代方案是 Ed25519 使用的替代方案，其中單個 SHA512 呼叫生成一個 512 位數字，該數字以曲線順序為模減少。我們的建築是不同的，但受此啟發。不過有一些變化：
- 我們不需要 512 位散列和模歸約，同樣因為曲線階數接近2 256，所以我們可以直接使用 256 位散列而不需要歸約。
- 我們擔心簽名者的公鑰取自不受信任的輸入的實現（大多數簽名 API 似乎無法防止這種情況，因為從私鑰重新創建公鑰會降低性能）。Greg Maxwell 就這個問題開始了關於這個密碼學郵件列表的討論：https ://moderncrypto.org/mail-archive/curves/2020/001012.html ，它收到了來自 DJB 和其他人的評論。我們通過將公鑰包含在隨機數生成中來解決這個問題。
- 我們試圖通過鼓勵合成隨機數（在可用時包含實際隨機性）來防止故障攻擊和差分功率分析攻擊。RFC6979 也有一個支持這一點的變體，但似乎由於我們使用線性派生的私鑰（通過 BIP32 和通過 Taproot），DPA 攻擊更難防禦，標準解決方案可能不適用。請參閱此處的比特幣開發郵件列表討論：https ://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-March/017711.html （我同意 OP 的觀點，即我們的一些設計選擇在還沒有）