一个比 /dev/random 更快但在加密上有用的 RNG？

Question

我已经开始了一些工作，其中需要一些质量随机字节，例如每次 32 个用于某些加密应用程序的初始化向量。我的问题是，这可能会同时被多次调用，我无法承受 /dev/random 块问题等待更多的熵收集。

我可以用它来播种其他算法，例如 /dev/urandom 可能会做什么 - 但是我不相信我无法理解的东西，我没有任何现成的可用资源，我也不知道它是否仍然是在许多内核版本之间都是一样的，我更喜欢某种定义明确的方法。

您是否知道您能想到的标准 PRNG 之外的任何方法，这些方法足以适用于（同时）密钥生成等？

某些密码（例如具有大种子的 RC4）是否足以生成随机输出？ （我见过一个使用它的 /dev/frandom 实现，但我并不完全确定。）

如果这意味着什么，我在一个无头的 Debian 服务器上，因为缺少熵收集。

Answer 1

响应很简单：使用/dev/urandom，而不是/dev/random。 /dev/urandom 是加密安全的，不会阻塞。 /dev/random 优于 /dev/urandom 的“优越性”仅存在于特定的理论设置中，如果随机字节与几乎任何“正常”加密算法（例如加密或签名）一起使用，这将毫无意义。

更多详情请见this。

（相信我，我是一名密码学家。）

Answer 2

考虑使用硬件随机数生成器。例如，entropy key 或 Whirlygig。改用/dev/urandom 可以避免阻塞，但可能（取决于您的偏执程度）降低安全性（您将输出比输入熵更多的随机位，因此理论上输出是可预测的 - 如果您这样做，这不是问题'只是将它用于静脉注射）

Answer 3

在具有 AES 硬件加速的现代 CPU 上，您可以通过使用随机密码（来自 /dev/urandom）加密一串零，轻松达到超过 1 GiB/s 的随机数据，如由another answer on serverfault 显示。请注意，随机密码是作为管道传递的，因此它不会显示在进程列表中。

在我的机器上，这种方法比 /dev/urandom 快大约 100 倍：

$ openssl enc -aes-256-ctr -pass file:<(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64) -nosalt < /dev/zero | pv > /dev/null
11.2GiB 0:00:09 [1.23GiB/s] [           <=>                           ]
$
$ # Let's look at /dev/urandom for comparison:
$ pv < /dev/urandom > /dev/null
  48MiB 0:00:04 [12.4MiB/s] [     <=>                                 ]

如果你把它放在一个 shell 脚本中，你可以很容易地将它通过管道传递给其他进程：

$ cat ~/.bin/fast_random 
#!/bin/bash
openssl enc -aes-256-ctr \
    -pass file:<(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64) \
    -nosalt < /dev/zero