7

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

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

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

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

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

4

3 回答 3

16

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

有关更多详细信息，请参阅此内容。

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

于 2011-08-04T23:00:00.803 回答
1

考虑使用硬件随机数生成器。例如，熵键或Whirlygig。使用/dev/urandom代替将避免阻塞，但可能（取决于您的偏执程度）降低安全性（您将输出比输入熵更多的随机位，因此理论上输出是可预测的 - 如果您只是但是将其用于IV）

于 2011-08-04T23:15:58.500 回答
1

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

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

$ 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
于 2017-04-20T14:36:58.807 回答