Soluzione 1:
Il tuo sistema raccoglie alcuni numeri casuali "reali" tenendo d'occhio diversi eventi:attività di rete, generatore di numeri casuali hardware (se disponibile; ad esempio i processori VIA di solito hanno un generatore di numeri casuali "reali") e così via. Se li alimenta al pool di entropia del kernel, che viene utilizzato da /dev/random. Le applicazioni che richiedono una sicurezza estrema tendono a utilizzare /dev/random come fonte di entropia o, in altre parole, fonte di casualità.
Se /dev/random esaurisce l'entropia disponibile, non è in grado di offrire più casualità e l'applicazione in attesa della casualità si blocca finché non sono disponibili più elementi casuali. L'esempio che ho visto durante la mia carriera è che il demone IMAP di Cyrus voleva usare /dev/random per la casualità e le sue sessioni POP volevano generare le stringhe casuali nelle connessioni APOP da /dev/random. In un ambiente frenetico c'erano più tentativi di accesso che traffico per l'alimentazione di /dev/random -> tutto bloccato. In quel caso ho installato rng-tools e attivato il rngd che aveva -- che spalava numeri semi-casuali da /dev/urandom a /dev/random nel caso in cui /dev/random avesse esaurito l'entropia "reale".
Soluzione 2:
Se desideri una panoramica più semplice del problema sottostante:alcune applicazioni (come la crittografia) richiedono numeri casuali. Puoi generare numeri casuali usando un algoritmo, ma sebbene questi sembrino casuali in un certo senso, sono totalmente prevedibili in un altro. Ad esempio, se ti do le cifre 58209749445923078164062862089986280348253421170679, sembrano piuttosto casuali. Ma se ti rendi conto che in realtà sono cifre del PI, saprai che la prossima sarà 8.
Per alcune applicazioni questo va bene, ma per altre applicazioni (specialmente quelle relative alla sicurezza) le persone vogliono una vera casualità imprevedibile, che non può essere generata da un algoritmo (cioè un programma) poiché è per definizione prevedibile. Questo è un problema in quanto il tuo computer essenzialmente lo è un programma, quindi come può ottenere numeri casuali autentici? La risposta è misurare eventi veramente casuali dal mondo esterno, ad esempio gli intervalli tra le pressioni dei tasti e utilizzarli per iniettare una vera casualità nel generatore di numeri casuali altrimenti prevedibile. Il "pool di entropia" potrebbe essere pensato come il deposito di questa casualità che viene accumulata dalle sequenze di tasti (o qualunque cosa venga utilizzata) e prosciugata dalla generazione di numeri casuali.
Soluzione 3:
Entropia è un termine tecnico per "casualità". I computer non generano veramente entropia ma la raccolgono osservando cose come le variazioni della velocità di rotazione del disco rigido (un fenomeno fisico che è molto difficile da prevedere a causa dell'attrito ecc.) Quando un computer vuole generare dati pseudo casuali, seminerà un formula matematica con vera entropia che ha trovato misurando i clic del mouse, le variazioni di rotazione del disco rigido ecc. In parole povere entropy_avail è la misura dei bit attualmente disponibili per essere letti da /dev/random
Ci vuole tempo perché il computer legga l'entropia dal suo ambiente, a meno che non abbia un hardware interessante come un diodo rumoroso o qualcosa del genere.
Se hai 4096 bit di entropia disponibili e cat /dev/random puoi aspettarti di essere in grado di leggere 512 byte di entropia (4096 bit) prima che il file si blocchi mentre attende più entropia.
Ad esempio, se "cat /dev/random ” la tua entropia si ridurrà a zero. All'inizio otterrai 512 byte di spazzatura casuale, ma si fermerà e a poco a poco vedrai passare più dati casuali.
Non è così che le persone dovrebbero agire /dev/random anche se. Normalmente gli sviluppatori leggono una piccola quantità di dati, come 128 bit, e li usano per seminare una sorta di algoritmo PRNG. È educato non leggere più entropia da /dev/random del necessario poiché richiede così tanto tempo per accumularsi ed è considerato prezioso. Quindi, se lo prosciughi con noncuranza cat tingendo il file come sopra farai in modo che altre applicazioni debbano leggere da /dev/random bloccare. Su un sistema al lavoro abbiamo notato che molte funzioni crittografiche si stavano bloccando. Abbiamo scoperto che un cron job stava chiamando uno script python che continuava a inizializzare ramdom.random() su ogni corsa che correva ogni pochi secondi. Per risolvere questo problema abbiamo riscritto lo script python in modo che venisse eseguito come un demone inizializzato solo una volta e il processo cron leggesse i dati tramite XMLRPC in modo che non continuasse a leggere da /dev/random all'avvio.
Soluzione 4:
Il file di sola lettura entropy_avail fornisce l'entropia disponibile. Normalmente, questo sarà 4096 (bit), un pool di entropia completo.
Puoi leggere di più su:http://linux.die.net/man/4/random