我理解/dev/urandom 了吗？

我一直在阅读关于 /dev/urandom的文章，据我所知，/dev/random利用网络数据包计时等一些事件创建加密随机数。然而，我是否正确地理解了 /dev/urandom使用了一个 PRNG，并从 /dev/random中获得了一个数字？或者它只是使用 /dev/random，只要有位——当它们用完时，它回落到一些 PRNG 与从哪里收集的种子？

52976 次浏览
小开
最佳答案

来自 urandom页面:

随机数生成器聚集 设备产生的环境噪声 驱动程序和其他来源转换为 熵池，还有发电机 保持对数量的估计 熵池中的噪音位。 从这个熵池随机数 被创造出来。

读取时,/dev/Random 设备 将只返回内部的随机字节 估计的噪声位数 在熵池中 应该适用于需要的用途 非常高质量的随机性 作为一次性便笺簿或钥匙 当熵池 是空的，从/dev/Random will 读取 阻止 直到附加环境 噪音被收集。

从/dev/urandom 设备读取不会阻塞等待更多信息 因此，如果有 熵中没有足够的熵 池，则返回的值为 从理论上来说 对算法的加密攻击 司机使用的。知道如何 这是不可用的 目前的非机密文献，但 从理论上讲，这样的 攻击可能存在。如果这是一个 在你的申请中，使用 取而代之的是/dev/Random。

两者都使用 PRNG，尽管使用环境数据和熵池使得破解 PRNG 难上加难，而且不收集完全相同的环境数据是不可能的。

根据经验，如果没有专门昂贵的硬件从量子事件中收集数据，就不会有真正的随机数生成器(例如，一个生成真正不可预测数字的 RNG) ; 尽管出于加密目的,/dev/Random 或/dev/urandom 就足够了(使用的方法是 CPRNG，加密伪随机数生成器)。

熵池和/dev/Random 的阻塞读取被用来作为一个安全保护，以确保不可能预测随机数; 例如，如果一个攻击者耗尽了系统的熵池，那么他就有可能预测到/dev/urandom 的输出，虽然在今天的技术下这是非常不可能的，因为它已经很长时间没有被重新播种了(尽管这样做也需要攻击者耗尽系统收集更多熵的能力，这也是天文数学上不可能的)。

小开

实际上，您在实践中需要的是 FreeBSD 的 /dev/urandom所提供的: 它将从 /dev/random读取足够长度的初始种子，然后使用 PRNG。因此，它最初可能会阻塞(在系统启动之后) ，但是一旦它收集了足够的熵，它就永远不会阻塞。这提供了大多数加密协议所需的随机性级别，同时没有过度阻塞。

Linux 的 /dev/urandom类似，只是它永远不会阻塞，因此如果在引导后使用它，可能会返回低质量的随机性。另一方面，/dev/random甚至可能在启动时间过后很长时间才阻塞，这也是一个问题。我经常看到服务器莫名其妙地停止运行，因为一些软件坚持使用 /dev/random，而没有键盘的服务器没有得到足够的熵。

通常的 Linux 发行版在关闭时保存从 /dev/urandom获得的随机种子，并在下一次引导时注入它，从而保证 /dev/urandom提供的随机种子的质量。只有在操作系统安装期间，加密质量才会成为一个问题，而且通常并不是因为安装涉及到与执行安装的人进行大量的交互，从而产生大量的熵。

总之，在 Linux 和 FreeBSD 下，应该使用 /dev/urandom，而不是 /dev/random。

小开

引用 给你

/dev/random将在熵池耗尽后阻塞。它将一直处于封闭状态，直到从熵的来源收集到更多可用的数据。这会减慢随机数据生成的速度。

/dev/urandom不会阻塞，相反，它会重用内部池来产生更多的伪随机位。

/dev/urandom最好在以下情况下使用:

  • 您只需要一个包含随机数据的大文件来进行某种测试。
  • 您正在使用 dd命令将磁盘替换为随机数据，从而从磁盘上擦除数据。
  • 几乎所有其他地方，你没有一个真正好的理由使用 /dev/random代替。

在以下情况下，/dev/random可能是更好的选择:

  • 随机性对于应用程序中加密的安全性至关重要——一次性垫、密钥生成。

提交答案