在 MuSig-DN 中，為什麼不對隨機數使用真正的隨機數而不是偽隨機函式？
在MuSig-DN 中，為什麼不對隨機數使用真正的隨機數而不是偽隨機函式 (PRF)？如果 nonce 空間足夠大，它將永遠不會被重用。
這個問題是 emzy 在Twitter 上提出的。
Tim Ruffing 在Twitter 上回答了這個問題。
答案很簡單，在實踐中獲得真正的隨機數並不容易。例如，您需要在系統中收集熵，並且很難編寫一個“測試”來檢查您的數字是否真的是隨機的。
損壞的隨機數生成器導致了許多現實世界的故障，例如
<https://www.schneier.com/blog/archives/2008/05/random_number_b.html>
和
<https://arstechnica.com/information-technology/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/>
因此，最好在實踐中簡單地避免使用真正的隨機數生成器，這是“正常”單歌手簽名（Schnorr sigs，ECDSA）的公認最佳實踐。MuSig-DN 也使多重簽名成為可能。
但你的觀點在理論上是正確的。如果你有一個真正隨機數的工作源，這將完成這項工作。
Pieter Wuille 和 Jonas Nick 在Twitter 上補充道：
隨機數的工作源以及在簽名過程的輪次之間安全地保存它們和防篡改的地方。
或者只是一個地方，在簽名會話之間安全地保持櫃檯和防篡改。理想地與 RNG 結合使用。
但這對於私鑰的生成也是如此，我們在那裡容忍嗎？
完全正確，是的。我認為這裡的答案有兩個：
- 我們至少可以盡量避免實數。即使對於密鑰生成，我們也可以從單個種子中派生所有密鑰，然後我們在錢包的生命週期中真正依賴隨機性來獲取該種子
- 當涉及到簽名中使用的隨機數時，隨機性似乎特別脆弱。例如，如果您修復了 nonce 中的一個位，那麼一些簽名可能已經足以派生密鑰。
也許我的第二點甚至不是一個有效的。我對具體攻擊知之甚少，無法判斷當我們修復密鑰中的一個位（而不是隨機數）時簽名是否突然變得不安全？
Diego Aranha 在Twitter 上補充道：
您的第二點在應用於 nonce 時是有效的，但是對於 1 位偏差（對於 secp256k1 的可行複雜度的攻擊來說，大約需要 2^60 的簽名）。修復私鑰的位應該只是減少密鑰空間
Akira Takahashi 在Twitter 上補充道：
事實上，攻擊比特幣 ECDSA 的 1 位隨機數偏差目前是遙不可及的，但考慮到大約 100 萬個簽名，2 位偏差已經可以利用，而 3 位只需要數千個（如果格子攻擊有效，甚至更少）。不確定有偏見的私鑰有多糟糕。
一個中間解決方案是包含一些 nonce 作為 PRF 輸入。這樣，即使 nonce 不是真正隨機的（證明：https : //ia.cr/2016/290），您也可以保持安全性，並且它應該可以阻止在沒有 ZKP 的情況下對 Schnorr 多重簽名的毀滅性回溯攻擊。
但需要明確的是，一旦誠實的簽名者重用 nonce，這個解決方案仍然會失效。處理這樣一個有狀態的方案很煩人，這就是為什麼像 MuSig-DN 這樣的純無狀態解決方案在實踐中是首選的原因。