Jos*_*sey 35 linux ubuntu entropy-pool
如果我在 Ubuntu 中运行这个命令
sudo cat /proc/sys/kernel/random/entropy_avail
它返回一个数字，表明内核可用多少“熵”，但这就是我所知道的。这个熵的测量单位是什么？它是干什么用的？有人告诉我，如果这个数字“低”，那就是“糟糕”。“低”有多低，如果是，会发生什么“坏”事？它在什么范围内是好的？它是如何确定的？
Jan*_*nen 27
您的系统通过关注不同事件来收集一些“真实”随机数：网络活动、硬件随机数生成器（如果可用；例如 VIA 处理器通常具有“真实”随机数生成器）等等。如果将它们提供给内核熵池，由 /dev/random 使用。需要一些极端安全性的应用程序倾向于使用 /dev/random 作为它们的熵源，或者换句话说，随机源。
如果 /dev/random 用完可用的熵，它就无法提供更多的随机性，等待随机性的应用程序会停止，直到有更多的随机性可用。我在职业生涯中看到的例子是 Cyrus IMAP 守护进程想要使用 /dev/random 来实现随机性，它的 POP 会话想要从 /dev/random 生成 APOP 连接中的随机字符串。在繁忙的环境中，用于提供 /dev/random 的登录尝试次数多于流量 -> 一切都停止了。在那种情况下，我安装了 rng-tools 并激活了它的 rngd —— 将半随机数从 /dev/urandom 铲到 /dev/random 以防 /dev/random 耗尽“真实”熵。
Jus*_*inP 27
如果您想更简单地了解基本问题：某些应用程序（例如加密）需要随机数。您可以使用算法生成随机数 - 但尽管这些在某种意义上看起来是随机的，但在另一种意义上却是完全可以预测的。例如，如果我给你数字 58209749445923078164062862089986280348253421170679，它们看起来很随机。但是如果你意识到它们实际上是 PI 的数字，那么你就会知道下一个将是 8。
对于某些应用程序，这是可以的，但对于其他应用程序（尤其是与安全相关的应用程序），人们想要真正的不可预测的随机性 - 这不能由算法（即程序）生成，因为根据定义，这是可预测的。这是一个问题，因为您的计算机本质上是一个程序，那么它怎么可能获得真正的随机数呢？答案是通过测量来自外部世界的真正随机事件 - 例如您的按键之间的间隙，并使用这些将真正的随机性注入到其他可预测的随机数生成器中。“熵池”可以被认为是这种随机性的存储，它通过击键（或正在使用的任何东西）建立起来并通过随机数的生成而耗尽。
小智 12
熵是“随机性”的技术术语。计算机并没有真正生成熵，而是通过查看诸如硬盘驱动器旋转速度的变化（由于摩擦等而很难预测的物理现象）之类的东西来收集它。当计算机想要生成伪随机数据时，它会通过测量鼠标点击、硬盘驱动器旋转变化等找到一个具有真实熵的数学公式。粗略地说，这entropy_avail是当前可供读取的位的度量/dev/random
计算机从环境中读取熵需要时间，除非它有很酷的硬件，比如嘈杂的二极管或其他东西。
如果您有 4096 位可用的熵，并且您/dev/random希望能够在文件阻塞之前读取 512 字节的熵（4096 位），同时等待更多的熵。
例如，如果您“ cat /dev/random”，您的熵将缩小为零。起初你会得到 512 字节的随机垃圾，但它会停止，一点一点地你会看到更多的随机数据涓流。
但这不是人们应该如何操作/dev/random。通常开发人员会读取少量数据，如 128 位，并使用它来为某种 PRNG 算法做种子。不读取/dev/random比您需要的更多的熵是有礼貌的，因为需要很长时间才能建立并且被认为是有价值的。因此，如果您cat像上面那样不经意地删除文件，则会导致其他需要读取的应用程序/dev/random阻塞。在工作中的一个系统上，我们注意到很多加密功能都停止了。我们发现一个 cron 作业正在调用一个不断初始化的 python 脚本ramdom.random()在每几秒钟运行一次的每次运行中。为了解决这个问题，我们重写了 python 脚本，使它作为一个守护进程运行，只初始化一次，cron 作业将通过 XMLRPC 读取数据，这样它就不会/dev/random在启动时继续读取。
只读文件 entropy_avail 给出了可用的熵。通常，这将是 4096（位），一个完整的熵池。
您可以在以下位置阅读更多信息：http : //linux.die.net/man/4/random