我可以從 iOS 中的 /dev/urandom 獲得多少位熵？
Apple最新的安全文件表明它現在使用 CTR_DRBG 生成偽隨機數（以前是 Yarrow 而不是 CTR_DRBG），使用“啟動期間的時序變化”和“設備啟動後的中斷時序”作為種子。預設情況下，呼叫iOS API SecRandomCopyBytes將從 /dev/random 中檢索隨機字節。蘋果的random(4) 手冊頁似乎暗示他們的 /dev/random 是非阻塞的，但它在某種程度上不需要阻塞以確保新的熵字節：
/dev/urandom 是對 Linux 的兼容性。在 Linux 上，如果熵池耗盡，/dev/urandom 將產生較低質量的輸出，而 /dev/random 將更喜歡阻塞並等待收集額外的熵。使用 Yarrow，這種選擇和區分是不必要的，兩種設備的行為相同。你可以使用任何一個。
NIST 的DRBG 驗證列表表明 Apple 在計數器模式下使用 AES-128 作為 CTR_DRBG 的偽隨機函式。
那麼，我們可以從 SecRandomCopyBytes 中期望多少位熵？如果我查詢它的 256 位熵，我是否會得到 128 位合理的熵數據，由於 iOS 的 /dev/random 中缺乏阻塞，可能會得到另外 128 位的較少熵數據？
我最近向 Craig Federighi 發送了有關此問題的郵件，擔心 macOS 無法生成 >128 位質量的密鑰。
他回應了！
“你引用的來源已經過時了。您可以在此處找到更多最新資訊：FIPS 認證文件，第 7 節：“NDRNG 將池中的熵按需提供給 DRBG。NDRNG 提供 256 位的熵。”
NIST 需要 128 位熵來為 CTR_DRBG 播種 AES-128，因此您可以放心地假設。如果您要求 256 位數據，理論上攻擊者有可能通過 128 位攻擊來攻擊 RNG：
假設一個 256 位的隨機值被請求兩次，攻擊者看到第一個，我們將其表示為 $ x_1||x_2 $ （兩個 128 位 AES 輸出）。然後他們可以迭代所有 128 位密鑰並選擇 $ D_k(x_1) + 1 = D_k(x_2) $ （至少有一個，可能不多）。然後，他們可以預測 PRNG 的下一個狀態及其下一個輸出（從這些匹配狀態中的一個派生而來）。
當然，在實踐中 128 位複雜度攻擊也是不可行的，所以你應該是安全的。但是，嚴格來說，您不能假設您使用該密鑰具有 256 位安全性。至少除非您還假設攻擊者沒有看到以前的 PRNG 輸出。
順便說一句，這個：
在 Linux 上，如果熵池耗盡，/dev/urandom 將產生較低質量的輸出，而 /dev/random 將更喜歡阻塞並等待收集額外的熵。
基本上是FUD。無論熵池消耗了多少，輸出的質量都不會降低。只要事先收集了足夠的熵，即使您請求足夠的數據來耗盡熵計數，隨機數生成器的狀態也是不可預測的。這些池是 4096 位，這遠遠超過了安全方案所必需的。