何时使用/ dev / random与/ dev / urandom

我应该使用/dev/random还是/dev/urandom？

在哪种情况下，我会优先选择一种？

TL; DR

使用/dev/urandom最实用的目的。

更长的答案取决于您所运行的Unix风格。

的Linux

从历史上看，/dev/random并且/dev/urandom都是同时引入的。

正如@DavidSchwartz 在评论中指出的那样，/dev/urandom在大多数情况下，首选使用。他和其他人还提供了有关/dev/urandom这篇文章的出色神话的链接，我建议您进一步阅读。

综上所述：

• 手册页有误导性
• 两者都由同一个 CSPRNG馈送以生成随机性（图2和3）
• /dev/random 当熵用完时阻塞
• 熵的数量是保守估计的，但不计算在内
• /dev/urandom永远不会阻塞，从中读取/dev/random可能会暂停进程执行。
• 在极少数情况下，启动后不久，CSPRNG可能没有足够的熵来正确植入种子，并且/dev/urandom可能不会产生高质量的随机性。
• 如果CSPRNG最初正确地播种，则熵变低不是问题
• CSPRNG不断被重新播种
• 在Linux 4.8及更高版本中，/dev/urandom不会耗尽熵池（用于/dev/random），而是使用上游的CSPRNG输出。
• 使用/dev/urandom。

规则例外

在加密协议栈交易所的时候使用/dev/random了/dev/urandomLinux中 @otus 给出了两个用例：

1. 在低熵设备上启动后不久，如果尚未生成足够的熵以正确播种/dev/urandom。

2. 生成具有信息理论安全性的一次性便笺本

如果您担心（1），可以检查中的可用熵/dev/random。

如果您正在做（2），您已经知道了:)

注意：您可以检查/ dev / random的读取是否会阻止，但要注意可能出现的竞争状况。

替代：不使用！

@otus还指出，getrandom()系统将/dev/urandom仅在初始种子熵不可用时从中读取并阻塞。

更改/dev/urandom使用getrandom()存在一些问题，但是可以想象/dev/xrandom基于来创建新设备getrandom()。

苹果系统

没关系，正如 Wikipedia所说：

macOS使用基于SHA1的160位Yarrow。/ dev / random和/ dev / urandom之间没有区别；两者的行为相同。苹果的iOS也使用Yarrow。

FreeBSD

没关系，正如Wikipedia所说：

/dev/urandom只是一个链接/dev/random，只有在正确播种后才能阻止。

这意味着在引导之后，FreeBSD足够聪明，可以等待直到收集到足够的种子熵，然后再提供无休止的随机优势流。

NetBSD

使用/dev/urandom，假设您的系统已从中读取了至少一次，/dev/random以确保正确的初始播种。

该RND（4）用户手册说：

/dev/urandom 永不阻塞。

/dev/random有时会阻塞。如果已知系统状态是可预测的，它将在启动时提前阻止。

当应用程序需要随机生成的数据（例如，加密密钥或用于模拟的种子）时，应从/ dev / urandom中读取。

为了避免可预测地生成密钥，在运行任何与Internet进行通信或需要加密的服务之前，应将系统设计为在启动时明智地从/ dev / random至少一次读取一次。

传统上，/dev/urandom和之间的唯一区别/dev/random是当内核认为系统中没有熵时发生- /dev/random关闭/dev/urandom失败，打开失败。两名司机均从采购熵add_disk_randomness()，add_interrupt_randomness()和add_input_randomness()。有关详细信息/drivers/char/random.c，请参见。

编辑添加：从Linux 4.8开始，/dev/urandom已重新使用CSPRNG。

那么什么时候应该关闭失败？对于任何类型的加密用途，特别是播种DRBG。有一篇很好的论文解释了/dev/urandom生成RSA密钥时使用时的后果以及熵不足。阅读挖掘你的P和Q。

这在某种程度上是“我也是”的答案，但它加强了汤姆·黑尔的建议。它直接适用于Linux。

• 采用 /dev/urandom
• 不要使用 /dev/random

根据Linux Kernel Crypto邮件列表上的Theodore Ts'o的说法，/dev/random已弃用十年。从回复：[RFC PATCH v12 3/4] Linux随机数生成器：

几乎没有人使用/ dev / random。本质上，它是一个已弃用的接口；十多年来，推荐的主要接口是/ dev / urandom，现在是getrandom（2）。

我们会定期测试/dev/random，并且经常遇到故障。该测试执行三个步骤：（1）/dev/random通过在非阻塞模式下请求10K字节进行消耗；（2）在阻止模式下请求16个字节（3）尝试压缩该块以查看其是否为随机（穷人测试）。测试需要几分钟才能完成。

在Debain系统（i686，x86_64，ARM和MIPS）上，问题是如此严重，我们要求GCC编译场rng-tools为他们的测试机安装软件包。从在gcc67和gcc68上安装rng-tools：

我想要求在gcc67和gcc68上安装rng-tools。它们是Debian系统，在使用该设备的酷刑测试库时，/ dev / random在没有rng-tools的情况下会遭受熵消耗。

BSD和OS X似乎确定。问题肯定是Linux。

值得一提的是Linux不记录生成器故障。他们不希望这些条目填满系统日志。迄今为止，大多数故障都是无声的，大多数用户无法检测到。

这种情况应该很快改变，因为内核将至少打印一条故障消息。从[PATCH]中随机：静默编译器警告并修复内核加密邮件列表中的争用：

具体来说，我添加了depends on DEBUG_KERNEL。这意味着这些有用的警告只会戳其他内核开发人员。这可能正是我们想要的。如果各个相关的开发人员看到来自其特定子系统的警告，则他们会更有动力进行修复。分发内核上的普通用户根本不会看到警告或垃圾邮件，因为通常用户不使用DEBUG_KERNEL。

我认为从安全工程的角度抑制所有消息是一个坏主意。

许多人不运行调试内核。大多数想要或需要了解问题的用户不会意识到它的发生。考虑一下，我们了解systemd问题的原因是dmesg的原因。

禁止所有配置的所有消息会覆盖比必要范围更广的网络。可能不会被检测到并已修复的配置将不会被注意到。如果未发现问题，则不会解决。

我觉得内核正在为某些组织制定政策决策。对于那些拥有实际上不可修复的硬件的企业，组织必须根据其风险逆境来决定要做什么。他们可能决定承担风险，或者可能决定更新硬件。但是，如果没有有关此问题的信息，他们甚至可能没有意识到自己有一个可行的项目。

最终在线程中达到的折衷方案是每个调用模块至少一个dmesg。