PRNG 中海綿函式的使用和限制
此 HRNG使用 SHA3 作為海綿函式（在其設備驅動程序中）將 ots 原始源輸出膨脹到許多 MByte/s。他們將此輸出速率與其他不使用海綿函式的 HRNG 的輸出進行比較。我想知道這種比較是否公平，並讓我想到應該使用海綿函式擴展 RNG 的問題。目標應該是獲得適合密碼操作（例如密鑰生成）的熵。
編輯：換句話說，如果海綿函式可用於在不降低熵的情況下將 300 kByte/s 膨脹到 500 MByte/s，為什麼 - 談論 Linux - 使用 /dev/random 而不是 /dev/urandom全部？
**使用 /dev/random 的唯一原因是等到系統載入 entropy。如果您已經等待過一次，通常使用 /dev/urandom 是安全的。**它與輸出速度 無關。沒有理由在應用程序中從 /dev/random 讀取超過一個字節。編寫一個基準來衡量從 /dev/random 讀取長輸出的時間是不稱職的，幾乎是不誠實的。編寫像 GnuPG 這樣從 /dev/random 讀取多個字節的應用程序是無能的，幾乎是瀆職。唯一的藉口是 /dev/random 的歷史文件也是近乎巫術的無能。
一般來說，為了安全起見，任何隨機數生成器都必須至少具有最小量的熵（例如 256 位），之後您可以使用您喜歡的任何偽隨機數生成器安全地繪製任意長的輸出。 有非常好的基於流密碼的 PRNG。有非常好的基於海綿的 PRNG。只要它提供足夠的安全級別，您選擇哪個安全性就沒有太大區別。
沒有理由 PRNG 必須與熵源位於同一硬體 IC 上。 實際上，最好在將熵源連接到 PRNG 之前仔細檢查熵源的原始輸出，以確認它具有預測的偏差。 如果 IC 只儲存一個密鑰ķ $ k $ 和一個計數C=0,1,2,… $ c = 0, 1, 2, \dots $ 向它發出的請求數，並返回一個和小號-256ķ(C) $ \operatorname{AES-256}_k(c) $ ，您將無法將其與真正的熵源區分開來。當然，向您出售這些設備的對手可能會為它所宣傳的物理系統編寫一個精心製作的模擬器，但如果您製作自己的免費硬體設計實例，則不會複製。