使用 Linux 的 /dev/urandom 生成加密密鑰時存在哪些問題？
從 Linux 5.1 開始，
/dev/random不再使用阻塞池。在移除 Linux /dev/random 阻塞池頁面上有一個關於更改的討論我相信 Linux 的阻塞池已經過時了。Linux 的 CRNG 生成的輸出足以用於密鑰生成。阻塞池在任何物質上都沒有更強大，並且保持它需要大量價值可疑的基礎設施。
這個系列不應該破壞任何現有的程序。/dev/urandom 沒有改變。/dev/random 在啟動後仍然會阻塞，但它會比以前阻塞更少。帶有現有標誌的 getentropy() 將返回輸出，即出於實際目的，與以前一樣強大。
Lutomirski 指出，核心是否應該提供所謂的“真正的隨機數”仍然是一個懸而未決的問題，這在一定程度上就是阻塞池的目的。他只能看到一個理由：“符合政府標準”。他建議，如果核心要提供這一點，它應該通過一個完全不同的介面來完成——或者通過提供一種方法讓核心提取可用於創建這樣一個阻塞池的原始事件樣本，將其推送到使用者空間。
然後
對於真正需要 TRNG 的密碼學家和其他人，Ts’o 也贊成為他們提供一種在使用者空間中收集自己的熵的方法，以便在他們認為合適的時候使用。他說，熵收集不是核心可以在它支持的所有不同硬體上可靠地完成的事情，也不能估計不同來源提供的熵量。（粗體是我的）
那麼，在使用 Linux生成加密密鑰****時存在哪些問題？
/dev/urandom
當作業系統
/dev/urandom的狀態不唯一時，用於生成加密密鑰或機密可能是一個問題。這是剛從模板啟動 VM 的典型情況：CSPRNG 的狀態可以在多個 VM 之間共享。在與此類似的情況下，使用/dev/randomorgetrandom()代替很重要/dev/urandom，這樣 CSPRNG 的輸出會阻塞，直到它收集到足夠的熵。當然，VM 複製需要重新啟動或從關閉狀態啟動，以便將熵計數重置為零。
/dev/urandom和的輸出/dev/random來自ChaCha20。一旦使用足夠的熵初始化 ChaCha20 的內部狀態，要考慮創建加密密鑰是不安全的，必須：
- 知道ChaCha20的內在狀態，
- 或破解 ChaCha20 密碼，該密碼如今被認為是最安全的密碼之一。
剩下的問題是如何計算熵。Linux 核心在這一點上非常保守，CSPRNG 的內部狀態很可能比計算的熵要多得多（大約多兩個數量級）。但是，要準確計算它在數學上是不可能的。
*免責聲明：*此答案適用於從4.8版到 5.9版的 Linux 核心，這是撰寫此答案時的最新版本。Linux CSPRNG 在 4.8 版（引入了 ChaCha20 密碼）和 5.6 版（架構的簡化）中進行了大量重構，在 4.17 版和後續版本中引入了微小的變化。