gpg关键一代的尾翼直播cd -为什么这么快？

Question

我只是使用gpg2 --gen-key在运行在live (Tails)上的操作系统上生成一个2048位RSA密钥对。这比我预期的要快得多。当我以前在一台普通机器上这样做时，它需要一些时间，我通常需要等待并做一些其他的事情。我认为这是因为产生所需的随机性需要一些时间。

一个活动cd是否有一些不寻常的进程，以至于引导过程产生的比正常的随机性更多？或者它是否有可能使用/dev/urandom代替？据我所知，gpg使用/dev/random，这就是为什么生成密钥需要花费一些时间。

Answer 1

我找到了答案:尾巴上有随机数发生器'haveged‘。http://www.reddit.com/r/tails/comments/2oxr7n/how_有吗？_反面_生成_gpg_关键字_所以_快/

我编辑了这个问题的标题，以反映这是独特的尾翼。

这里有一些关于HAVEGED算法是否有用的讨论：https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged

与使用/dev/random相比，gpg在使用/dev/urandom时所采取的保守方法在许多情况下可能会过度使用，但从没有时间限制的用于gpg密钥生成的活动CD环境的具体角度来看，使用haveged似乎是不必要的。

因此，在我看来，最简单的解决方案是杀死Tails中的已有进程，等待/proc/sys/内核/随机/熵_效耗尽，然后让gpg只做它通常做的事情。

Answer 2

熵(“随机性”)是在内核中积累的。如果内核在GPG启动之前积累了足够的熵，那么GPG将立即从中受益。

Linux对熵的处理有点中断。Linux有两个设备：/dev/random和/dev/urandom。/dev/random块只要能积累足够的熵就行。/dev/urandom总是不阻塞地返回数据。原则上，这将是一件好事。问题是Linux的熵计算是非常保守的:它假定熵被耗尽，这只有在高度理论的意义上才是正确的。因此，/dev/random倾向于在不应该阻止的情况下阻止它。

在正常系统中，您应该使用只管用/dev/urandom - though 有些软件，包括gpg，没有给你选择的余地。然而，在一张活动CD上，在启动后，可能会有很小的熵，除非您的计算机有硬件RNG (例如最近英特尔处理器上的兰德指令 )，并且Linux支持它。因此，在这种情况下，您确实需要使用/dev/random，并在必要时等待。用户交互(例如移动鼠标)将导致这种熵。

另见为GPG密钥添加“随机数熵”？和你能解释一下随机数中使用的熵估计吗？

同样，您不必担心: GPG+Linux在估计熵时非常保守。如果GPG快速生成密钥，则要么您已经与计算机进行了足够的交互以提供足够的熵，要么您的计算机具有支持的硬件RNG。

Answer 3

首先，/dev/urandom和/dev/random的区别在于，/dev/random会阻塞，直到有足够的熵生成一个随机数，而/dev/urandom在熵耗尽时不会阻塞。这也意味着/dev/urandom应用程序上的生成可以比来自/dev/random的数字更少的随机性。

对于您的问题，生成秘密的运行时取决于系统中可用的熵以及您能够快速获得两个素数(而不耗尽熵池)的幸运程度。

如果您始终在Tails上快速生成一个键区，那么这个实现可能有问题。