标签: entropy-pool

如果我在 Ubuntu 中运行这个命令

sudo cat /proc/sys/kernel/random/entropy_avail

它返回一个数字，表明内核可用多少“熵”，但这就是我所知道的。这个熵的测量单位是什么？它是干什么用的？有人告诉我，如果这个数字“低”，那就是“糟糕”。“低”有多低，如果是，会发生什么“坏”事？它在什么范围内是好的？它是如何确定的？

您可能知道，在虚拟机上生成熵并不像在“普通”PC 上那么容易。即使使用正确的工具，在虚拟机上生成 gpg 密钥也可能需要一段时间。

那里有更多的加密函数，它们不像 gpg 那样具有熵意识。

那么可以说加密在虚拟机上的安全性较低吗？

我最近第一次遇到了一个耗尽的熵池，我很失望地发现没有一个常用的系统日志有助于发现问题。

在新的 CentOS 6 虚拟机上安装 CUPS 后，我尝试通过 HTTPS 连接到管理页面。该请求似乎无限期挂起。后来我了解到 CUPS 正在尝试动态生成一个新的自签名 SSL 证书，并且在尝试从 /dev/random 读取时被阻止。在互联网上进一步阅读表明，这是虚拟机的常见问题，因为它们缺乏通常的熵来源。

尽管在我的特定情况下很容易解决，但我现在怀疑在我的 ESXi 群集中的其他虚拟机上可能会发生类似的耗尽事件。但是由于此事件未写入任何通常的日志文件，因此我真的无法知道这个问题有多普遍。

有什么方法可以轻松监控大型集群中所有虚拟机的熵可用性吗？特别是，我想知道熵耗竭是否是我们在某些机器上看到的一些间歇性性能问题的一个促成因素。

我有几个熵键，它们前面有 egd，然后所有负载都由 haproxy 平衡。然后我有许多客户端机器使用 haproxy 服务 IP 作为网络熵源。我不知道他们要求多少熵。

熵键可以产生有限数量的可用熵。规范说最低大约为 30 KB/秒。据我所知，Entropy Key 没有办法查询它的请求量。EGD 协议似乎很难找到这些信息。客户端可以请求可变数量的熵，但他们可能不会得到相同数量的熵。

有没有人找到一种简单的方法来测量从熵键请求的数量？

最好知道，以便能够计划何时需要额外的密钥，并发现失控的客户。

在我的 Apache 配置中，我有以下几行：

SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/random
SSLRandomSeed connect file:/dev/urandom 1024

Apache 如何解释这一点？它是否首先尝试内置，然后/dev/random在失败时转向？如果它使用/dev/random，/dev/random然后用完熵，它会自动切换到/dev/urandom吗？是否有一个 Apache 文档可以解释所有这些？

RHEL 5.x 存在熵生成问题（从内核2.4保留）。遵循此处的指示几乎没有产生任何结果：

如何在没有键盘/鼠标的 2.6 内核 RHEL/Fedora 系统上增加熵池。

随机数生成需要良好的熵源。这会影响通过 SSL 传输的服务等。在 2.6 内核中，系统的熵源是键盘、鼠标和一些 IRQ 中断。linux 上有两个随机数源 - /dev/random 和 /dev/urandom。如果熵位桶中没有任何东西， /dev/random 将阻塞。如果您的系统没有键盘和鼠标，您可以使用 'rngd' 守护程序来执行任务。您可以使用以下命令查看熵值。

    #cat /proc/sys/kernel/random/entropy_avail  

Run Code Online (Sandbox Code Playgroud)

现在，使用以下命令启动“rngd”守护程序并监视系统上的熵。

    #rngd -r /dev/urandom -o /dev/random -f -t 1
    #watch -n 1 cat /proc/sys/kernel/random/entropy_avail

Run Code Online (Sandbox Code Playgroud)

此问题还有哪些其他修复程序可用？

背景

由于 RHEL 5 上的熵池较小，当前版本的 Server Automation 中的一个组件存在一个已知问题（在 HP 方面），该问题需要很长时间才能启动。我正在尝试找到一种解决方法，直到/除非它已修复在供应商方面。

最近我们遇到了一个问题，由于长期缺乏“熵”，我们的一个基于 Linux 的虚拟机真的很慢。

我想知道 Windows 虚拟机是否会遇到同样的问题。（谷歌搜索没有给我相关的命中，但我可能使用了错误的搜索词。）

自从昨天重新启动以来，我们的一个虚拟服务器（Debian Lenny，使用 Xen 虚拟化）不断耗尽熵，导致尝试通过 SSH / TLS 启用协议进行连接时超时等。有没有办法检查哪个进程正在（/正在）吃掉所有的熵？

编辑：

我试过的：

• 添加额外的熵源：time_entropyd、rng-tools 将 urandom 反馈回随机、伪随机文件访问——每秒获得大约 1 MiB 的额外熵，问题仍然存在
• 通过 lsof、netstat 和 tcpdump 检查异常活动 – 没有。没有明显的负载或任何东西
• 停止守护进程，重新启动永久会话，重新启动整个虚拟机——行为没有变化

什么最终奏效：

• 等待。从昨天中午开始，不再有连接问题。熵仍然有点低（128 字节峰值），但 TLS/SSH 会话不再有明显的延迟。我正在慢慢地将我们的客户端切换回 TLS（所有五个！），但我认为现在行为不会有任何变化。所有客户端现在都再次使用 TLS，没问题。真的，真的很奇怪。

我正在尝试了解 下的 linux 内核参数/proc/sys/kernel/random/，但我遇到了一些麻烦。你能帮我弄清楚一些事情吗？

1. 什么是boot_id使用的参数？我只找到了它在启动时生成的信息，但我找不到原因。
2. 我知道熵池大小是恒定的（4096 位）并且不能改变。为什么这个数字这么小？难道不能是 1048576 或更多吗？也许有很多可用的熵不是很好吗？
3. 它类似于第二个问题，但涉及entropy_avail参数——不填充整个熵池的目的是什么？当我检查参数时，它在 1000 位左右振荡，但池大小为 4096。当entropy_avail达到 中设置的阈值时write_wakeup_threshold，它会下降一点（通常为 100），然后再次上升到write_wakeup_threshold参数中指定的点。那么为什么我们在熵池大小中需要这个 4096 呢？
4. 我有什么理由应该增加或减少read_wakeup_threshold和write_wakeup_threshold参数的值？第一个只是让需要/dev/random设备熵的进程休眠，但是当我将它设置为 64、128 或 256 时有什么区别？它只是挂了更长的时间，或者还有别的什么吗？

我在想我的熵水平可能很低？

$ cat /proc/sys/kernel/random/entropy_avail

我平均在 132-178 左右。池大小默认为 4096（顺便说一下，这是虚拟器上的容器）。

我也跑了：

$ cat /dev/urandom | rngtest -c 1000

并得到：

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 999
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=26.272; avg=628.845; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=73.928; avg=108.740; max=130.640)Mibits/s
rngtest: Program …

我正在 kubernetes 集群上试用 coreos。此设置包括一个服务 DNSSEC 响应的绑定服务器。由于 DNSSEC 密钥管理，绑定服务器用完所有可用的熵并在启动时挂起，并且需要数小时才能获得足够的熵来签署单个区域。

我可以做些什么来增加服务器上的熵以防止这种情况发生？