Per quanto tempo ri-seminare / dev / urandom in una macchina virtuale?

Ho letto molto sulla distinzione tra /dev/random e /dev/urandom . Capisco che il consiglio prevalente è di usare /dev/urandom . La spiegazione - che 256 bit di casualità "corretta" sono tutto ciò che serve per quasi tutte le applicazioni crittografiche - ha senso per me.
Un paio di fonti utili:
- link
- link

Lo stato di una macchina virtuale (VM) o di un CD live subito dopo il primo avvio è talvolta identificato come caso limite insolito rispetto a questa linea guida, poiché /dev/urandom potrebbe non essere stato seminato correttamente.

Nel contesto di tutti gli altri possibili usi di /dev/urandom , posso vedere che questo è un caso limite. Tuttavia, dato che stai usando una VM per la prima volta, sembra plausibile che una delle prime cose che potresti voler fare è chiamare su /dev/urandom , ad es. per generare chiavi SSH.

Quindi, se si assume il peggio della VM (ad esempio che è stata clonata o che dopo un riavvio i nuovi randoms non sono validi), cosa si può fare per assicurarsi che /dev/urandom sia buono per andare?

La cosa più pigra da fare sembra essere quella di lasciare che la VM resti attiva per un po 'di tempo, fino a quando gli eventi casuali non avranno seminato il pool di input. La parte imbarazzante è che una VM inattiva lo fa abbastanza lentamente.

Volevo testare quanto tempo ci voleva perché ciò accadesse, e ho provato a farlo come segue:

Questo comando estrae 32 byte / 256 bit dal pool (e visualizza in hex)
head -c 32 </dev/random | xxd -p

Una volta che il conteggio entropico del pool di input è passato a livelli minimi (visibile con cat /proc/sys/kernel/random/entropy_avail ), il comando precedente verrà bloccato fino a quando nuovi eventi casuali non entreranno nel pool di input. Questo mi suggerisce che se eseguiamo ripetutamente il comando sopra riportato, lo calcoliamo e scriviamo i risultati in un file chiamato randomtest , indicherà quanto tempo ci vuole per riempire il pool di input.

Ho provato a scrivere un comando a riga singola che lo fa:
for n in {1..10}; do (/usr/bin/time -f "%E Real" sh -c 'printf "%-10s" $(head -c 32 </dev/random | xxd -p)' 2>&1) >> randomtest; done

Più facilmente:

for n in {1..10};
do (/usr/bin/time -f "%E Real" sh -c \
    'printf "%-10s" $(head -c 32 </dev/random | xxd -p)' 2>&1) \
    >> randomtest; 
done

So che i processi di partenza (anche il comando cat sopra) disegna il pool di input, quindi questo fornirà una stima prudente. Per quello che vale, lascio che il comando sopra indicato sia eseguito su una VM inattiva e il tempo tra le nuove sequenze a 32 byte è stato costante di 15-20 minuti ciascuna.

Le mie domande:

• L'output di questo comando verifica con successo ciò che penso che faccia?
• C'è un modo molto più semplice per testare la stessa cosa?
• Esiste un modo diverso / migliore "pigro" per aggiornare il pool di input e ri-seed /dev/urandom rispetto a lasciare la VM inattiva?