我需要使用加密强度高（认证要求）、高质量（通过行业标准随机性测试）且性能合理（见下文）的 PRNG。
最初，我认为它会在最新的 Ubuntu LTS 上运行，并计划从中读取/dev/urandom，因为根据我的信息，从内核版本 5.18 开始，它似乎满足了所有条件。
性能方面，{ timeout --foreground 1s cat /dev/urandom; } | wc -c在 M1 Mac（仅供参考）上运行实现了约 450MB/s 的吞吐量，并且我从 x86-64 Ubuntu 22.04.2 LTS VM 中获得了类似的结果。
读取 40kB 块的 C++ 程序实现了更高的约 1GB/秒吞吐量，但我无法在其上运行编译和运行可执行文件（尽管我假设 shell 命令和可执行文件之间的比率相似）。
然而，事实证明它将部署在虚拟机中运行的 Amazon Linux 2（内核版本 5.10）上，这意味着算法的和表现RNG 的改进将不可用。
我的问题是：
- 在虚拟机上运行的内核 5.10是否
/dev/urandom仍然满足原始要求，即：提供加密的强伪随机数，并且还通过行业标准随机性测试，吞吐量至少为 1MB/秒？
我无法访问相关环境，但尝试使用早期内核版本的多个在线 shell 会产生不一致的结果：在几个系统上（内核5.4， 和内核5.15/dev/random）我从和获得了相同的吞吐量/dev/urandom，根据我的理解，这意味着相同的质量，但在另一个系统上（也内核5.4），/dev/random被阻止并给出 0-200B/s 之间的结果（即字节，没有前缀），表明/dev/urandom的质量下降了（除非我误解了什么）。
然而，根据菲罗尼克斯，”Linux 5.6 /dev/random 的行为更像 /dev/urandom 现在用于轮询用户空间中的 RNG 数据。更改后的行为导致 /dev/random 的行为与 /dev/urandom 相同，除了在 CRNG（Linux 加密强度随机数生成器）准备就绪之前读取被阻止之外。同时 /dev/urandom 将继续提供其最好的数据，但永远不会阻塞。”，因此上述使用内核 5.4 的测试对于这种情况可能无效。
所以看起来好像我可能会逃脱惩罚，但我不确定。
- 如果事实证明使用随机伪文件不是一个选项，那么有哪些替代方案可以勾选上面的复选框？会 OpenSSL 的兰德_字节符合要求吗？
答案1
据我了解，/dev/urandom已经得到了够好了CSPRNG 甚至在 5.4 中（它被移植到使用 ChaCha20在4.8， 和 两个都由相同 CSPRNG 支持的设备）。
后来的变化更大的重点不是 RNG 本身的改进（尽管确实发生了很多改进），而是认出CSPRNG 实际上足够好，并且由此消除了 的“由于熵核算而导致的阻塞”行为/dev/random，特别是因为大家一致认为 CSPRNG 足够好，不需要它。
换句话说，是的，根据我的理解，5.10 上的 /dev/urandom 将与 一样高质量/dev/random，后它的 CSPRNG 已初始化 - 尽管它不向用户空间提供任何指示是否已发生。
更好的选择可能是 getrandom(2) 系统调用（从 3.something 开始可用），它似乎提供了“两全其美”（又名新的 5.18/dev/random行为）——指定 0 作为标志，如果 CSPRNG 是，它将阻塞尚未准备好，但之后不会阻塞。
不过，由于缺乏上下文切换，用户空间 CSPRNG 总是会更快 – 它是非常通常使用/dev/urandom或getrandom()播种，例如 OpenSSL RAND_bytes() 或您选择的加密库提供的任何其他内容。 （我相信现代 OpenSSL 3.0 会getrandom()自动调用，因此您无需手动播种。）
（旁注：我pv /dev/urandom > /dev/null在附近的各种 x86 服务器上进行了测试，从 Westmere 到 Comet Lake，再加上 ARM64 Ampere Altra 上的 VPS，以进行良好的测量，并且它们全部达到相同的 300–400 MB/s。）
/dev/random 被阻止并给出 0-200B/s 之间的结果（即字节，没有前缀），表明 /dev/urandom 的质量下降了（除非我误解了某些内容）。
我相信最近变化的重点是认识到 /dev/urandom 的质量不如果它有良好的 CSPRNG 支持，那么它就会降级，并且 /dev/random 所做的计算毫无意义（因此它在 5.6 中被删除）。