gnupg 2.1.16 blocchi in attesa di entropia

Le versioni di gnupg dal 2.1.16 (attualmente 2.1.17) bloccano l'attesa dell'entropia solo alla prima invocazione .

Nota: questo non è un tentativo di generare una chiave, solo per decrittografare un file e avviare l'agente.

La prima volta che gpg-agent viene avviato, direttamente gpg2 file.gpgo usando un'applicazione come pass, appare pinentry e una volta che inserisco la mia passphrase e premo Entersi blocca per circa 15 secondi.

Tutte le chiamate successive, all'interno della finestra di default-cache-ttl, vengono eseguite immediatamente.

In esecuzione in --debug-allmodalità, il periodo in cui si verifica l'arresto si stampa ¹ :

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
...

Ho installato rng-tools per integrare il pool di entropia:

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

e confrontato con una macchina con la stessa versione di gnupg che non aveva installato rng-tools o che aveva installato, non mostra alcun ritardo:

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

Quindi sembra che ci sia abbastanza entropia nel pool. Questo è stato testato su kernel 4.8.13 e 4.9.

Gpg usa un pool diverso? Come posso fornire un'entropia sufficiente o altrimenti eliminare il ritardo di 15 secondi all'avvio dell'agente?

Penso di sapere cosa sta succedendo. Nell'agente / gpg-agent.c di gnupg, questa funzione elabora i messaggi da 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
}

L'ultima parte con npth_usleep è stata aggiunta tra la 2.1.15 e la 2.1.17. Dato che questo è condizionatamente compilato se libgcrypt è precedente alla 1.8.0, la soluzione semplice sarebbe ricompilare gnupg contro libgcrypt 1.8.0 o successive ... sfortunatamente quella versione non sembra esistere ancora.

La cosa strana è che quel commento sulla lettura / dev / random di libgcrypt non è vero. Stracciare l'agente rivela che sta leggendo da / dev / urandom e usando il nuovo syscall getrandom (2), senza bloccare. Tuttavia, invia molti messaggi need_entropy, causando il blocco di npth_usleep. L'eliminazione di quelle righe risolve il problema.

Devo dire che npth sembra essere una specie di libreria multitasking cooperativa, e npth_usleep è probabilmente il suo modo di cedere, quindi potrebbe essere meglio ridurre in modo significativo quel ritardo, nel caso in cui libgcrypt decida di bloccare un giorno. (1ms non è evidente)