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代替将避免阻塞，但可能（取决于你的偏执程度）会降低安全性（你输出的输出熵比输入熵更多，所以理论上输出是可预测的 - 这不是问题如果你只是用它来制作IVs的话）

Answer 3

您可以尝试使用/bin/ps -A v或/bin/ps -A s的输出（或其散列）。但是，我不确定该命令是否适用于所有或大多数Linux发行版。

如果您决定使用/dev/urandom，则应计算从该源生成的随机字节的熵，最好是min-entropy。

Answer 4

在具有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

RNG比/ dev / random更快但加密有用吗？

4 个答案: