简短的回答是，/dev/random用 的输出进行反馈/dev/urandom不会降低安全性。为了让事情更清楚（评论表明我不够精确），我的观点是/dev/random用 的输出喂养/dev/urandom是无害的（尽管它不会增加安全性）；它也相当无用（除了作为一种轻松支持应用程序的方式，这些应用程序坚持/dev/random在不合时宜的时间无缘无故地使用和阻塞）。

为简单起见，让我们定义一个运行的工作模型/dev/randomand /dev/urandom：

• 有一个内部状态p由k个字节组成（对于某个整数k）。
• 通过将p替换为H ( p , x )来注入额外的熵x，其中H是“某种”散列函数。例如，当前状态与新熵连接，结果被散列，散列输出是新的p。
• 通过使用p作为CSPRNG的输入来产生输出；前k个字节是p的新值，后续字节是该运行的输出。
• /dev/random不同之处/dev/urandom在于它偶尔会拒绝输出字节，直到注入新的熵（或从硬件收集）。

（以上是一个概念模型，对于当前讨论而言，它与实际实现非常接近。）

整个事物的安全性取决于p的熵；粗略地说，攻击者不知道多少p 。攻击者知道p的大小为k，因此他们可能会尝试通过蛮力猜测p ，平均成本约为 2 ^{8 k -1}。CSPRNG 被认为是加密安全的，因为对输出的许多字节的分析不会产生关于其他输出字节的信息——特别是，它不会产生关于p的信息（在运行之前或之后）。

我们现在假设x是由攻击者选择的。只要H表现得像一个安全散列函数，H ( p , x ) 就具有与p相同的熵——攻击者在操作后仍然没有关于p的信息。严格来说，如果允许攻击者执行“熵供给”技巧 2 ^{8 k /2}次，则可能会产生“空间减少”效果，减小到大约 2 ^{8 k /2的大小。}如果k足够大（比如 32，对于 256 位内部状态），剩余空间大小仍然足够大以保证安全，并且 这种情况无论如何都达不到。

由于 CSPRNG 不会产生关于p的信息，因此 CSPRNG 的输出在安全性方面不会比攻击者控制的x更差。这是以学术方式形式化的最棘手的部分（这需要几页才能正确写下来）。直观地说，CSPRNG 在使用k字节的输入和k字节的输出时，其行为就像一个随机预言机。

/dev/random因此，从输出中馈送/dev/urandom不会降低安全性。

这当然依赖于状态更新函数（用于熵注入）和 CSPRNG 都是“理想”函数的想法。如果他们不是，那么你无论如何都注定要失败（/dev/random在这种情况下，自动阻止行为不会拯救你）。

不幸的是，有些人更喜欢/dev/randomFIPS 和 Common Criteria。[编辑：我找不到它的引用，但请参阅底部的非官方来源] 因此，如果您希望您的软件获得 FIPS / CC 认证，它不能使用/dev/urandom. 它必须证明它保持对熵的准确估计，并且当熵低时它必须阻塞。

简要背景：

所有确定性随机数生成器仅与它们的种子一样随机。熵是对您的种子的随机性（或意外或不可预测）的估计。为了增加 RNG 的熵，您需要混合来自外部来源的新鲜随机性。如果您可以访问不可预测的数据源（通常是人工输入设备上的计时或热噪声），那么请务必将其输入/dev/random以增加其种子的熵。

Linux 内核将自动混入尽可能多的随机源，包括数据包时序、击键时序、来自进程调度程序的随机性、附加的硬件随机数生成器（开始包含在消费者主板上）。那太好了。

我知道的唯一/dev/random一个已知弱点的情况是在无头虚拟机上，因为不可预测性实际上没有任何东西可以拉动。

好吧，让我们进入真正的问题：

我想确定使用类似守护进程rngd或haveged恢复随机性/dev/random- 即使它们在大多数情况下基于/dev/urandom类似rngd- 不会引入弱点。

我的问题是：rngd,haveged和/dev/urandom从哪里获得随机性？它真的是来自机器外部的新随机性，还是只是重新散列/dev/random？

我无法与rngdor交谈haveged，但我知道在 Linux 上/dev/urandom与 RNG 共享一个 RNG /dev/random（请参阅这个很棒的咆哮，我从下面借用了一张图片），而在 FreeBSD/dev/urandom上实际上是一个指向 的指针/dev/random，所以很可能你'只是/dev/random反馈给自己。

我不是专家，无法知道这是否会引入弱点，但它肯定没有任何好处。

我在 FIPS 文档中唯一提到的“no /dev/urandom”是 2014 年的一份草案，该草案从未向公众发布。它包括脚注：

注意 2：假设 /dev/urandom 生成器不提供熵，除非它经过专门检测以始终确保至少 112 位的可用熵。

然后它继续列出可以保证熵的方法。这比我被引导相信的要少得多。酷，今天学会了！

不要将 hogwash 数据输入 /dev/random 等做可疑的事情。如果需要，可以将 /dev/random 替换为 /dev/urandom 的符号链接

您可以使用haveged或类似的东西，但不要在没有任何外部输入的情况下使用任何东西。havaged（另外，如果您运行虚拟化硬件，尤其要小心）

/dev/random 对熵不好的输入非常健壮，但是如果你输入太多废话，谁知道会发生什么？

/dev/urandom 众所周知并经过测试。如果您将 /dev/random 链接到它，您可能不会遇到问题。如果你做可疑的事情，你可能会遇到问题！

另外：您要负责什么：“重新启动后与我们服务器的第一次安全连接几乎需要一秒钟！！！”/“生成大量证书很慢”或“您对我们的随机东西所做的事情是完全坏了！我们所有的钥匙都坏了，我们所有的数据都被盗了！你做了什么？

明智地决定！