如何使用 AES-256-CTR 建構 CSPRNG？
我需要每秒生成數以千計的隨機 128 位 IV，並希望攤銷對
/dev/urandom.如何使用 AES-256-CTR 建構 CSPRNG？
例如，以下內容是否可以接受？
- 從
/dev/urandom.- 使用前 32 個字節作為 AES-256-CTR 密鑰。
- 使用接下來的 16 個字節作為 AES-256-CTR IV。
- 加密 65536 個字節的零。
- 將密文分成 4096 個 128 位 IV (65536 / 16)。
- 每 4096 次 IV 沖洗並重複步驟 1 至 6。
是一次加密 65536 個字節的零，還是一次加密 16 個字節的零（即明文的大小應該不超過密碼的塊大小）是否重要？
該方案是否會在 65536 字節的密文中平均拉伸 256 位 + 128 位熵（初始 AES 密鑰 + 初始 AES IV）？這如何轉化為從其中切出的每個 IV？每個 IV 是否至少有 128 位的熵，或者每個 IV 的熵會以某種方式減少？
如何改進這個方案？
要改進，請使用NIST SP 800-90A Rev. 1 Recommendation for Random Number Generation Using Deterministic RBGs，第 10.2.1 節：CTR_DRBG。
是一次加密 65536 個字節的零，還是一次加密 16 個字節的零（即明文的大小應該不超過密碼的塊大小）是否重要？
不，但是您可能想知道是否要將這麼多數據儲存在記憶體中。東西可能會從記憶體中清除，我不確定 64 KiB 緩衝區是否比 1 KiB 緩衝區快得多。
該方案是否會在 65536 字節的密文中平均拉伸 256 位 + 128 位熵（初始 AES 密鑰 + 初始 AES IV）？
是的，但請注意，這與說您已達到 384 位的安全強度不同。
這如何轉化為從其中切出的每個 IV？每個 IV 是否至少有 128 位的熵，或者每個 IV 的熵會以某種方式減少？
DRBG 的輸出不應與熵混淆，熵通常是 DRBG 的輸入。您應該擔心輸出是否可以與隨機區分，並且答案可能是否定的。
您的方案和 NIST 版本之間的主要區別在於您直接使用
/dev/urandom而不是 INITIALIZE 和 UPDATE 函式。我認為這通常不會造成問題，但是您會失去 NIST 在該方案中設置的任何安全性。請注意，這
/dev/urandom只是一個塊設備，其安全性在/dev/urandom很大程度上取決於實現。一些實現可能會在收集到足夠的熵之前返回數據；/dev/random沒有這個問題，但即使在收集到足夠的熵之後也可以並且確實會阻塞。