熵池與種子的隨機數生成
為了提供一點背景知識，我目前正在用 JavaScript 實現一個加密庫。
我已經開始移植 Linux 的隨機數生成器，因為它都經過了公開審查，它是開源的，並且有很好的文件記錄。在確定 Linux 的 RNG 之前瀏覽了其他實現之後，大多數其他實現（如 Mersenne Twister 和其他 PRNG）都使用單字節種子值作為它們的單一熵源，並添加更多熵，您只需將種子值與“流”進行異或熵”。然而，Linux 的 RNG 使用了一個熵池，正如它聽起來的那樣，它由一個更大的“種子”值數組組成，其中所有值都被認為具有大量的熵。要添加熵，您只需將熵 XOR 到池中，然後將其與一些多項式混合，然後將其全部散列以隱藏內部狀態。
我想知道的是在單字節種子值上使用熵池有什麼好處？這也引發了一個問題，考慮到 Linux 的 RNG 幾乎在全球範圍內用於整個核心以及每個需要隨機數據的應用程序，“種子”或熵源是否取決於其案例？如果一次只有一個應用程序使用 RNG，那麼單字節種子是否與更大的熵池一樣安全？如果其他應用程序從中提取隨機數據，Linux 使用熵池的唯一原因是不提供有關內部種子狀態的任何提示嗎？
我想我想問的是在熵池上使用單字節種子值有什麼好處，並且熵池是否與只有一個受信任的單個使用者使用 RNG 的單使用者 RNG 相關？
我想知道的是在單字節種子值上使用熵池有什麼好處？
熵池沒有任何好處。這是必需品。如果有的話，它是一個糟糕的真隨機數生成器 (TRNG) 的有力指標，並暗示該構造實際上是一個事實上的偽隨機數生成器 (PRNG)，我相信 /dev/random 就是這樣。
任何 TRNG 的黃金法則是 H(in) >= H(out)，其中 H 是熵。下圖說明了 Linux 隨機數生成器的熵池。
由於輸入事件完全不規則且頻率不確定，因此無法計算 H(in)。您可以輕鬆地等待 >60 秒以使單個隨機輸出字節可用。您提到 Linux 實現有據可查。不是為了這一點。我在文獻中找不到輸入熵的定量評估。最好的是底部的報告，但它仍然接受開發人員對 1 位熵/事件的評估。它可能要低得多，但如前所述，不能給不規則事件一個比率。沒有人對這些瞬間事件本身進行準確的熵測量。δ3s 不是有效的熵單位。因此，黃金法則尚未得到證實。
因此，熵池充當累加器和低通濾波器以平滑 jiffies。您將不得不在您的 Javascript 埠中自己實現這一點。反復對池進行雜湊處理非常類似於在擠壓階段海綿結構的重新排列，因此與 PRNG 是另一個平行的。
TRNG都是關於真實熵的，它是累積的。/dev/random 的任何埠都必須解決從機器擷取熵的問題，並且由於 Javascript 比核心更高度抽象，這將更加困難。但是游泳池將是不可避免的。當檢測到不規則的熵事件時，您不能輕鬆地逐字節和逐位地重新播種生成器的狀態。無論您是實現 /dev/random 的直接副本還是某些 NIST CSPRNG，您都需要池來作弊。它與並發應用程序的數量無關。您將熵池與連接池混淆了。
這個問題可能有點陳舊，但對於任何開發真正隨機數生成器的人來說，答案今天仍然適用。
參考。François Goichon、Cédric Lauradoux、Guillaume Salagnac、Thibaut Vuillemin。Linux 隨機數生成器中的熵傳輸。
$$ Research Report $$RR-8060，2012 年，第 26 頁。
在上面的評論中，我認為 Paul Uszak 一定是指 CSPRNG，而不是 TRNG（通過與非電腦世界的真正混亂相關的硬體實現）…… TRNG 可以用作很好的補充並將做出任何
$$ CS $$PRNG 工作得更好。 使用者空間熵操縱，即從應用層操縱熵通常應該被避免。堅持使用核心空間熵，它還具有更好地保護熵池周圍的記憶體空間的優勢。此外，您可以避免在操作熵池時出現人為錯誤。
正如 Paul Uszak 上面所寫，Seed 代替了最初的“空”熵池，並且僅在啟動時使用（當我們談論核心空間熵時，例如 /dev/
$$ u/a $$隨機的）