Questa domanda è piuttosto vecchia. Ma ancora rilevante, quindi darò la mia risposta. Molte CPU oggi sono dotate di un generatore di numeri casuali hardware (RNG) integrato. Inoltre, molti sistemi sono dotati di un TPM (Trusted Platform Module) che fornisce anche un RNG. Ci sono anche altre opzioni che possono essere acquistate, ma è probabile che il tuo computer abbia già qualcosa.
Puoi usare rngd dal pacchetto rng-utils sulla maggior parte delle distribuzioni Linux per seminare più dati casuali. Ad esempio su fedora 18 tutto quello che dovevo fare per abilitare il seeding dal TPM e dall'RNG della CPU (istruzione RDRAND) era:
# systemctl enable rngd
# systemctl start rngd
Puoi confrontare la velocità con e senza rngd. È una buona idea eseguire rngd -v -f dalla riga di comando. Questo ti mostrerà le fonti di entropia rilevate. Assicurati che tutti i moduli necessari per supportare le tue fonti siano caricati. Per utilizzare TPM, deve essere attivato tramite tpm-tools. aggiorna :ecco un bel howto.
A proposito, ho letto su Internet alcune preoccupazioni sul fatto che il TPM RNG venga spesso rotto in modi diversi, ma non ho letto nulla di concreto contro gli RNG trovati nei chip Intel, AMD e VIA. Usare più di una fonte sarebbe la cosa migliore se ti interessa davvero la qualità della casualità.
urandom va bene per la maggior parte dei casi d'uso (tranne a volte durante l'avvio anticipato). La maggior parte dei programmi al giorno d'oggi usa urandom invece di casuale. Anche openssl lo fa. Guarda i miti sull'urandom e il confronto di interfacce casuali.
Negli ultimi strumenti Fedora e RHEL/CentOS rng supportano anche l'entropia del jitter. Puoi farlo in mancanza di opzioni hardware o se semplicemente ti fidi più del tuo hardware.
AGGIORNAMENTO: un'altra opzione per più entropia è HAVEGED (qualità in discussione). Sulle macchine virtuali c'è un kvm/qemu VirtIORNG (consigliato).
AGGIORNAMENTO 2: In Linux 5.6 il kernel fa la propria entropia di jitter.
Sulla maggior parte dei sistemi Linux, /dev/random è alimentato dall'entropia effettiva raccolta dall'ambiente. Se il tuo sistema non fornisce una grande quantità di dati da /dev/random , probabilmente significa che non stai generando abbastanza casualità ambientale per alimentarlo.
Non sono sicuro del motivo per cui pensi /dev/urandom è "più lento" o di qualità superiore. Riutilizza un pool di entropia interno per generare pseudocasualità, rendendola di qualità leggermente inferiore, ma non si blocca. In genere, le applicazioni che non richiedono crittografia di alto livello o a lungo termine possono utilizzare /dev/urandom affidabile.
Prova ad aspettare un po' e poi a leggere da /dev/urandom ancora. È possibile che tu abbia esaurito il pool di entropia interno leggendo così tanto da /dev/random , interrompendo entrambi i generatori:consentire al tuo sistema di creare più entropia dovrebbe reintegrarli.
Vedi Wikipedia per maggiori informazioni su /dev/random e /dev/urandom .