我写了一个答案，详细描述了getrandom()块如何等待初始熵。

但是，我认为他稍微夸大了 urandom，他说“/dev/urandom 可能由于低熵而暗示安全问题的唯一时刻是在全新的自动化操作系统安装的最初时刻。”

你的担心是有根据的。关于那件事及其影响，我有一个悬而未决的问题。问题是持久随机种子需要相当长的时间才能从输入池移动到输出池（阻塞池和 CRNG）。此问题意味着/dev/urandom将在启动后的几分钟内输出潜在的可预测值。正如您所说，解决方案是使用block/dev/random或使用getrandom()set 来阻止。

事实上，在早期启动时在内核日志中看到这样的行并不少见：

random: sn: uninitialized urandom read (4 bytes read, 7 bits of entropy available)
random: sn: uninitialized urandom read (4 bytes read, 15 bits of entropy available)
random: sn: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
random: sn: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
random: sn: uninitialized urandom read (4 bytes read, 20 bits of entropy available)

所有这些都是在收集到足够的熵之前访问非阻塞池的实例。问题是熵的数量太低，以至于此时在密码学上是足够安全的。应该有 2 ^{32 个}可能的 4 字节值，但是只有 7 位可用熵，这意味着只有 2 ⁷或 128 种不同的可能性。

Halderman 似乎还说熵池在每次启动时都会填满，而不是像 Pornin 在他的回答中所说的那样，在第一次安装操作系统时。虽然它对我的应用程序来说并不是非常重要，但我想知道：它是什么？

这实际上是语义问题。实际熵池（保存在内核中的包含随机值的内存页）在每次启动时都会被持久熵种子和环境噪声填充。但是，熵种子本身是一个在安装时创建的文件，每次系统关闭时都会使用新的随机值进行更新。我想 Pornin 认为随机种子是熵池的一部分（例如，一般熵分配和收集系统的一部分），而 Halderman 认为它是独立的（因为熵池在技术上是内存，仅此而已）。事实是，熵种子在每次启动时都被送入熵池，但实际影响池可能需要几分钟。

三种随机性来源的总结：

1. /dev/random- 阻塞字符设备在每次读取时都会减少“熵计数”（尽管熵实际上并未耗尽）。但是，它也会阻塞，直到在启动时收集到足够的熵，使其在早期可以安全使用。

2. /dev/urandom- 每当有人从中读取时，非阻塞字符设备将输出随机数据。一旦收集到足够的熵，它将输出几乎无限的流，与随机数据无法区分。不幸的是，出于兼容性原因，即使在启动的早期，在收集到足够的一次性熵之前，它也是可读的。

3. getrandom()- 只要熵池已使用所需的最小熵正确初始化，系统调用就会输出随机数据。它默认从非阻塞池中读取。如果给定GRND_NONBLOCK标志，如果熵不足，它将返回错误。如果给定GRND_RANDOM标志，它的行为将与 相同/dev/random，只是阻塞直到有可用的熵。

我建议你使用第三个选项，getrandom()系统调用。这将允许进程以高速读取加密安全的随机数据，并且仅在没有收集到足够的熵时才会在启动早期阻塞。如果os.urandom()如您所说，Python 的函数充当此系统调用的包装器，那么使用它应该没问题。看起来实际上有很多关于是否应该是这种情况的讨论，最终导致它阻塞，直到有足够的熵可用。

再想一想：对于像我上面描述的那样新鲜和幼稚但在初始熵生成前景相当糟糕的设备上运行的环境的最佳实践是什么？

这是一种常见的情况，有几种处理方法：

• 确保在早期启动时阻止，例如使用/dev/randomor getrandom()。

• 如果可能的话，保留一个持久的随机种子（即，如果您可以在每次启动时写入存储）。

• 最重要的是，使用硬件 RNG。这是#1最有效的措施。

使用硬件随机数生成器非常重要。如果存在任何受支持的 HWRNG 接口，Linux 内核将使用任何支持的 HWRNG 接口初始化其熵池，从而完​​全消除引导熵漏洞。许多嵌入式设备都有自己的随机发生器。

这对于许多嵌入式设备来说尤其重要，因为它们可能没有内核安全地从环境噪声中生成熵所需的高分辨率计时器。例如，某些版本的 MIPS 处理器没有周期计数器。

您如何以及为什么建议使用 urandom 播种（我猜是用户空间？）CSPRNG？这如何击败 getrandom？

非阻塞随机设备不是为高性能而设计的。直到最近，由于使用 SHA-1 来实现随机性，而不是像现在这样使用流密码，因此该设备速度非常慢。使用内核接口实现随机性可能不如本地用户空间 CSPRNG 有效，因为每次调用内核都需要昂贵的上下文切换。内核的设计目的是考虑到应用程序想要大量使用它，但是源代码中的注释清楚地表明他们不认为这是正确的做法：

/*
 * Hack to deal with crazy userspace progams when they are all trying
 * to access /dev/urandom in parallel.  The programs are almost
 * certainly doing something terribly wrong, but we'll work around
 * their brain damage.
 */

OpenSSL 等流行的加密库支持生成随机数据。它们可以播种一次或偶尔重新播种，并且能够从并行化中受益更多。此外，它还可以编写不依赖于任何特定操作系统或操作系统版本的可移植代码。

如果你不需要大量的随机性，使用内核的接口是完全可以的。如果您正在开发一个在其整个生命周期中需要大量随机性的加密应用程序，您可能需要使用 OpenSSL 之类的库来为您处理。

系统可以处于三种状态：

1. 没有收集到足够的熵来安全地初始化 CPRNG。

2. 已收集到足够的熵以安全地初始化 CPRNG，并且：

   2a。释放的熵比它收集的要多。

   2b。释放的熵少于收集的熵。

从历史上看，人们认为（2a）和（2b）之间的区别很重要。这导致了两个问题。首先，这是错误的——这种区别对于设计合理的 CPRNG 来说毫无意义。其次，对 (2a)-vs-(2b) 区别的强调导致人们忽略了 (1) 和 (2) 之间的区别，这实际上非常重要。人们只是将（1）折叠成（2a）的特例。

你真正想要的是在状态（1）中阻塞的东西，而不是在状态（2a）或（2b）中阻塞的东西。

不幸的是，在过去，（1）和（2a）之间的混淆意味着这不是一个选择。您仅有的两个选项是/dev/random，在情况（1）和（2a）中被阻止，并且/dev/urandom，从未被阻止。但是状态 (1) 几乎永远不会发生——而且在配置良好的系统中根本不会发生，见下文——然后/dev/urandom几乎所有系统都更好，几乎所有时间。这就是所有那些关于“总是使用 urandom”的博客文章的来源——他们试图说服人们停止在 (2a) 和 (2b) 州之间做出无意义和有害的区分。

但是，是的，这些都不是你真正想要的。因此，较新的getrandom系统调用，默认情况下在状态 (1) 中阻塞，而不在状态 (2a) 或 (2b) 中阻塞。所以在现代 Linux 上，正统应该更新为：始终使用getrandom默认设置。

额外皱纹：

• getrandom还支持非默认模式，它的行为类似于/dev/random，可以通过GRND_RANDOM标志请求。AFAIK 这个标志实际上从来没有用过，原因与那些旧博客文章描述的所有相同的原因。不要使用它。

• getrandom还有一些额外的好处/dev/urandom：无论您的文件系统布局如何，它都可以工作，并且不需要打开文件描述符，这对于希望对将使用的环境做出最小假设的通用库来说都是有问题的。这不会影响加密安全性，但它在操作上很好。

• 配置良好的系统将始终具有可用的熵，即使在早期启动时也是如此（即，您永远永远不应该进入状态（1））。有很多方法可以解决这个问题：保存上一次启动的一些熵以在下一次启动时使用。安装硬件 RNG。Docker 容器使用主机的内核，因此可以访问其熵池。高质量的虚拟化设置有办法让客户系统通过管理程序接口从主机系统获取熵（例如搜索“virtio rng”）。但当然，并非所有系统都配置良好。如果您有一个配置不佳的系统，您应该看看是否可以将其配置得很好。原则上这应该很便宜，但实际上人们并不优先考虑安全性，所以......它可能需要做一些事情，比如切换云提供商，或切换到不同的嵌入式平台。不幸的是，您可能会发现这比您（或您的老板）愿意支付的要贵，因此您不得不处理配置不当的系统。如果是这样，我表示同情。

• 正如@forest 所指出的，如果您需要很多 CPRNG 值，那么如果您非常小心，您可以通过在用户空间中运行自己的 CPRNG 来加快速度，同时使用getrandom（重新）播种。不过，这在很大程度上是“仅限专家”的事情，就像您发现自己实现自己的加密原语的任何情况一样。仅当您测量并发现getrandom直接使用对您的需求而言太慢并且您具有重要的加密专业知识时，您才应该这样做。很容易搞砸 CPRNG 实现，从而完全破坏您的安全性，但输出仍然“看起来”是随机的，所以您不会注意到。