我需要使用加密强度高（认证要求）、高质量（通过行业标准随机性测试）且性能合理（见下文）的 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 产生了不一致的结果：在几个系统（kernel 5.4和kernel 5.15/dev/random ）上，我从和获得了相同的吞吐量/dev/urandom，根据我的理解意味着相同的质量，但在另一个系统（也是内核 5.4）上，/dev/random被阻止并给出 0-200B/s 之间的结果（即bytes，没有前缀），表明 的/dev/urandom质量已下降（除非我误解了某些内容）。
然而，根据Phoronix的说法，“ Linux 5.6 /dev/random 现在的行为更像 /dev/urandom，用于轮询用户空间中的 RNG 数据。更改后的行为导致 /dev/random 的行为与 /dev/urandom 相同，除了读取会被阻塞，直到 CRNG（Linux 加密强度随机数生成器）准备好为止。同时 /dev/urandom 将继续提供其最佳数据，但永远不会阻塞。”，因此上述使用内核 5.4 的测试可能对此无效案件。
所以看起来我可能会逃脱惩罚，但我不确定。
- 如果事实证明使用随机伪文件不是一个选项，那么有哪些替代方案可以勾选上面的复选框？OpenSSL 的RAND_Bytes是否符合要求？