gpg2 --gen-key私はLive CD（Tails）で実行されているオペレーティングシステムで2048ビットRSAキーペアを作成するために使用しました。これはすべて私が予想したよりもはるかに早く起こりました。以前に通常のコンピュータでこれを実行した場合は、時間がかかり、通常はしばらく待ってから別の作業を実行する必要があります。必要なランダム性を生成するのに時間がかかるからだと思います。
Live CDには、ブートプロセスが通常よりも多くのランダム性を引き起こす珍しいプロセスがありますか？それともそれが使用されている可能性がありますか/dev/urandom？私が知っている限り、gpgは/dev/randomそれを使用しているので、キーを生成するのに時間がかかるかもしれません。
答え1
エントロピー（「ランダム性」）はカーネルに蓄積されます。 GPGが始まる前にカーネルが十分なエントロピーを蓄積すると、GPGはすぐに利点を得ます。
Linuxのエントロピー処理に問題があります。 Linuxには2種類のデバイスがあります/dev/random。十分なエントロピーが蓄積される限りブロックされます。常にブロックせずにデータを返します。原則として、これは良いことです。問題は、Linuxのエントロピー計算が非常に保守的であるということです。つまり、エントロピーがすべて使い果たされると仮定します。これは非常に理論的な意味でのみ真実です。したがって、ブロックすべきではないときにブロックされる傾向があります。/dev/urandom/dev/random/dev/urandom/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場合、過剰である可能性がありますが、/dev/urandom時間制限のないgpgキーを生成するためのライブCD環境の特定の観点からは、hasgedを使用することは不要です。
したがって、私の考えの最も簡単な解決策は、Tailsで停止したプロセスを終了し、/proc/sys/kernel/random/entropy_availが排水されるのを待ってから、gpgに通常どおりに何かをするようにすることです。
答え3
/dev/urandomまず、との違いは、乱数を生成するのに十分なエントロピーがあるまでブロックし、/dev/randomエントロピーが使い果たされた場合はブロックしないことです。これもアプリの作成です。/dev/random/dev/urandom/dev/urandom/dev/random
問題の場合、秘密を生成する実行時間は、システムで利用可能なエントロピーとエントロピープールを使い果たすことなく、2つの素数をすばやく取得できる運に依存します。
Tailsで常に迅速にキーペアを生成する場合は、実装に問題がある可能性があります。