我只是用来gpg2 --gen-key在 Live CD (Tails) 上运行的操作系统上生成 2048 位 RSA 密钥对。这一切发生得比我预想的要快得多。当我以前在普通机器上完成此操作时，需要一些时间，并且我通常需要等待并短暂执行其他操作。我认为这是因为生成所需的随机性需要一些时间。
Live CD 是否有一些不寻常的过程，导致启动过程产生比正常情况更多的随机性？或者它有可能正在使用/dev/urandom吗？据我所知，gpg 使用/dev/random这就是为什么它可能需要一些时间来生成密钥。
答案1
熵（“随机性”）在内核中累积。如果内核在 GPG 启动之前积累了足够的熵，GPG 会立即从中受益。
Linux 对熵的处理有些问题。 Linux 有两种设备：/dev/random和/dev/urandom。/dev/random只要积累足够的熵，就会阻塞。/dev/urandom始终返回数据而不阻塞。原则上，这将是一件好事。问题在于Linux的熵计算极其保守：它假设熵会被用完，这仅在高度理论的意义上是正确的。因此/dev/random往往会在不应该阻塞的时候阻塞。
在正常的系统上，你应该只需使用/dev/urandom- 尽管一些软件，包括 gpg，不给你选择。然而，在 Live CD 上，启动后立即可能存在很少的熵，除非您的计算机有硬件 RNG（例如RdRand指令在最新的 Intel 处理器上）并且 Linux 支持它。所以在这种情况下你确实需要使用/dev/random并在必要时等待。用户交互（例如移动鼠标）将影响该熵。
也可以看看为 GPG 密钥添加“随机数熵”？和你能解释一下 random.c 中使用的熵估计吗
再次强调，您无需担心：GPG+Linux 在估计熵方面非常保守。如果 GPG 快速生成密钥，则要么您已经与计算机进行了足够的交互以提供足够的熵，要么您的计算机具有受支持的硬件 RNG。
答案2
我找到了答案：Tails 附带随机数生成器“haveged”。 http://www.reddit.com/r/tails/comments/2oxr7n/how_does_tails_generate_gpg_keys_so_fast/
我编辑了问题的标题，以反映这是 Tails 所特有的。
以下是关于 HAVEGED 算法是否好用的一些讨论：https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged
gpg 在使用时采取的保守方法/dev/random在很多情况下可能有点过头了，与 using 相比/dev/urandom，但从用于 gpg 密钥生成且没有时间限制的 live CD 环境的具体角度来看，使用 hasged 似乎没有必要。
所以在我看来，最简单的解决方案是杀死 Tails 中的 haged 进程，等待 /proc/sys/kernel/random/entropy_avail 耗尽，然后让 gpg 做它通常做的事情。
答案3
/dev/urandom首先，和之间的区别/dev/random在于，它将/dev/random阻塞直到有足够的熵来生成随机数，而/dev/urandom当熵耗尽时则不会阻塞。这也意味着应用程序上的生成/dev/urandom可能不如 中的数字随机/dev/random。
对于您的问题，生成秘密的运行时间根据系统中的可用熵以及您快速获得两个素数的幸运程度（不耗尽熵池）而有所不同。
如果您始终在 Tails 上快速生成密钥对，则实施可能存在问题。