Tails live cd 上的 gpg 密鑰生成 - 為什麼這麼快？
我只是用來
gpg2 --gen-key在執行在 live cd (Tails) 上的作業系統上生成一個 2048 位 RSA 密鑰對。這發生的速度比我預期的要快得多。當我之前在普通機器上完成此操作時，它需要一些時間，而且我通常需要等待並短暫地做一些其他事情。我認為這是因為生成所需的隨機性需要一些時間。live cd 是否有一些不尋常的過程，使得引導過程產生的隨機性超過了正常的隨機性？還是有可能它正在使用
/dev/urandom？據我所知，gpg 使用/dev/random這就是生成密鑰需要一些時間的原因。
/dev/urandom首先，和之間的區別在於/dev/random它將/dev/random阻塞直到有足夠的熵來生成隨機數，而/dev/urandom當熵耗盡時不會阻塞。這也意味著/dev/urandom應用程序上的生成可能比來自/dev/random.對於您的問題，生成秘密的執行時間取決於系統中可用的熵以及您快速獲得兩個素數的幸運程度（不會耗盡熵池）。
如果您始終獲得在 Tails 上快速生成的密鑰對，則實施可能存在問題。
熵（“隨機性”）在核心中累積。如果核心在 GPG 啟動之前已經積累了足夠的熵，GPG 會立即從中受益。
Linux 對熵的處理有些破損。Linux 有兩個設備：
/dev/random和/dev/urandom./dev/random只要積累足夠的熵就可以阻塞。/dev/urandom總是返回數據而不阻塞。原則上，這將是一件好事。問題在於 Linux 的熵計算非常保守：它假設熵被用完，這僅在高度理論意義上是正確的。所以/dev/random往往會在不應該的時候阻塞。在普通系統上，您應該只使用
/dev/urandom- 儘管某些軟體，包括 gpg，並沒有給您選擇。但是，在 Live CD 上，在啟動之後，熵可能很少，除非您的電腦具有硬體 RNG（例如最近的 Intel 處理器上的RdRand 指令）並且 Linux 支持它。因此，在這種情況下，您確實需要使用/dev/random並在必要時等待。使用者互動（例如移動滑鼠）將有助於這個熵。另請參閱為 GPG 密鑰添加“隨機數熵”？你能解釋一下 random.c 中使用的熵估計嗎
同樣，您不必擔心：GPG+Linux 在估計熵時非常保守。如果 GPG 快速生成密鑰，則要麼您已經與電腦進行了足夠多的互動以提供足夠的熵，要麼您的電腦具有受支持的硬體 RNG。