gnupg 2.1.16ブロックがエントロピーを待っています

リリースのGnuPG 2.1.16から（現在は2.1.17）のエントロピーを待ってブロックするだけで最初の呼び出しで。

注：これは、キーを生成する試みではなく、ファイルを復号化してエージェントを起動するためだけのものです。

初めてgpg-agentを起動すると、直接gpg2 file.gpgまたはのようなアプリケーションを使用してpasspinentryが表示され、パスフレーズを入力してヒットEnterすると、約15秒間ハングします。

default-cache-ttlのウィンドウ内の後続のすべての呼び出しは、すぐに実行されます。

--debug-allモードで実行すると、ハングが発生する期間が出力されます¹：

gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 120 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 120 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
...

エントロピープールを補足するためにrng-toolsをインストールしました。

cat /proc/sys/kernel/random/entropy_avail 
4094

そして、RNG-ツールを持っていなかったあるいはGnuPGの同じバージョンのマシンと比較しhaveged：何の遅延を示さないインストールし、

cat /proc/sys/kernel/random/entropy_avail
3783

だから、そこに表示されたプール内に十分なエントロピーこと。これはカーネル4.8.13と4.9でテストされました。

gpgは別のプールを使用しますか？エージェントを開始するときに、十分なエントロピーを提供する、または15秒の遅延を解消するにはどうすればよいですか？

何が起こっているのかわかっていると思います。gnupgのagent / gpg-agent.cでは、この関数はlibgcryptからのメッセージを処理します。

/* This is our callback function for gcrypt progress messages.  It is
   set once at startup and dispatches progress messages to the
   corresponding threads of the agent.  */
static void 
agent_libgcrypt_progress_cb (void *data, const char *what, int printchar,
                             int current, int total)
{
  struct progress_dispatch_s *dispatch;
  npth_t mytid = npth_self ();

  (void)data;

  for (dispatch = progress_dispatch_list; dispatch; dispatch = dispatch->next)
    if (dispatch->ctrl && dispatch->tid == mytid)
      break;
  if (dispatch && dispatch->cb)
    dispatch->cb (dispatch->ctrl, what, printchar, current, total);

  /* Libgcrypt < 1.8 does not know about nPth and thus when it reads
   * from /dev/random this will block the process.  To mitigate this
   * problem we take a short nap when Libgcrypt tells us that it needs
   * more entropy.  This way other threads have chance to run.  */
#if GCRYPT_VERSION_NUMBER < 0x010800 /* 1.8.0 */
  if (what && !strcmp (what, "need_entropy"))
    npth_usleep (100000); /* 100ms */
#endif
}

npth_usleepの最後の部分は、2.1.15と2.1.17の間に追加されました。libgcryptが1.8.0より古い場合、これは条件付きでコンパイルされるため、簡単な修正はgnupgをlibgcrypt 1.8.0以降に対して再コンパイルすることです...残念ながら、そのバージョンはまだ存在していないようです。

奇妙なことに、/ dev / randomを読み取るlibgcryptに関するコメントは真実ではありません。エージェントをストレーシングすると、/ dev / urandomから読み取っており、ブロックせずに新しいgetrandom（2）syscallを使用していることがわかります。ただし、多くのneed_entropyメッセージを送信するため、npth_usleepがブロックされます。これらの行を削除すると、問題が修正されます。

npthはある種の協調マルチタスクライブラリのようであり、npth_usleepがおそらく生成する方法であるため、libgcryptがいつかブロックすることを決定した場合に備えて、その遅延を大幅に削減する方が良いかもしれないことを言及しておきます。（1msは目立ちません）