Entropia è richiesto nel seguente senso: se un PRNG ha solo n bit di entropia, vuol dire che ha (concettualmente) solo 2 < em> n possibili stati interni, e quindi potrebbe essere suddiviso in enumerazione brutale di questi 2 n stati, a condizione che n è sufficientemente basso perché un tale attacco di forza bruta sia fattibile.
Quindi le cose diventano complesse, perché il "livello di entropia" riportato dal kernel NON è l'entropia. Non quello di cui parlo sopra.
Da un punto di vista crittografico , l'algoritmo che calcola l'output di entrambi /dev/random e /dev/urandom è un (presumibilmente) PRNG crittograficamente sicuro . Ciò che conta per la sicurezza pratica è, infatti, l'entropia accumulata dello stato interno. Escludendo le carenze crittografiche in quel PRNG (nessuno è noto al momento), quell'entropia può solo aumentare o rimanere costante nel tempo. Infatti, "entropia" può anche essere chiamata "ciò che l'attaccante non sa" e se il PRNG è effettivamente crittograficamente sicuro, quindi, per definizione, l'osservazione di gigabyte di output produce solo informazioni trascurabili sullo stato interno. Questo è ciò che crittograficamente sicuro significa.
Pertanto, se /dev/urandom aveva 200 bit di entropia a un certo punto dall'ultimo avvio, allora ancora ha 200 bit di entropia, o anche di più.
Dal punto di vista di chiunque abbia scritto quel codice (e la temuta pagina man corrispondente), l'entropia è "depleta" dopo l'uso. Questa è la posizione di qualcuno che assume, per il gusto dell'argomento, che il PRNG è non crittograficamente sicuro, ed è in effetti in qualche modo equivalente a emettere semplicemente lo stato interno così com'è. Da quel punto di vista, se /dev/random inizia con n bit di entropia e output k bit, allora ha ora nk bit di entropia .
Tuttavia, questo punto di vista non è alla fine sostenibile, perché mentre si basa sul presupposto che il PRNG sia completamente rotto e una non-operazione, è anche basato, allo stesso tempo , partendo dal presupposto che il PRNG è ancora crittograficamente abbastanza sicuro da trasformare "l'entropia dell'hardware" (le fonti di elementi di dati che si presume siano in qualche modo casuali) in una sequenza di bit uniforme e omogenea. In poche parole, la nozione di esaurimento dell'entropia funziona solo fino a quando assumiamo l'ipotesi estrema che il PRNG sia del tutto debole, ma sotto questa ipotesi la stima di quanto entropia sia veramente è completamente fuori.
In sostanza, quel punto di vista è contraddittorio. Sfortunatamente, /dev/random implementa una strategia di blocco basata su questa errata stima dell'entropia, il che è piuttosto scomodo.
/dev/urandom non blocca mai , indipendentemente da quanto "entropia hardware" è stata raccolta dall'ultimo avvio. Tuttavia, nelle installazioni "normali" di Linux, un seme casuale viene inserito all'inizio del processo di avvio; quel seme è stato salvato all'avvio precedente e si rinnova immediatamente dopo l'inserimento. Quel seme per lo più estende l'entropia di /dev/urandom tra i riavvii. Quindi l'asserzione diventa: se /dev/urandom aveva 200 bit di entropia in qualsiasi momento da quando il sistema operativo è stato installato per la prima volta , allora ha ancora 200 bit di entropia.
Questo comportamento può ancora essere un po 'problematico per alcuni casi specifici, ad es. avvio senza disco. La macchina di avvio potrebbe aver bisogno di un po 'di prima di avere accesso ai suoi file (ad es. Per stabilire un IPsec contesto necessario per raggiungere il server che contiene i suddetti file). Un'implementazione migliore di /dev/urandom verrebbe bloccata fino a quando non è stata raccolta una quantità sufficiente di entropia hardware (ad esempio 128 bit), ma produrrebbe bit "per sempre", senza implementare una sorta di esaurimento di entropia. Questo è esattamente ciò che fa /dev/urandom di FreeBSD. E questo è buono.
Riepilogo: non preoccuparti. Se il PRNG utilizzato nel kernel è crittograficamente sicuro, come sembra, allora il conteggio "entropy_avail" non ha senso. Se il PRNG utilizzato nel kernel è non crittograficamente sicuro, allora il conteggio "entropy_avail" è ancora imperfetto, e comunque sei nei guai più profondi.
Si noti che le istantanee VM interrompono l'entropia, poiché il comportamento della VM dopo il ripristino funzionerà sempre sullo stato che è stato salvato nell'istantanea e divergerà solo attraverso l'accumulo di nuovi eventi hardware (che possono essere complicati in un VM, dal momento che l'hardware della VM non è vero hardware). Il contatore "entropy_avail" del kernel e il comportamento di blocco /dev/random , cambiano niente affatto . Lo snapshot / ripristino VM è una vulnerabilità di sicurezza molto più plausibile per il PRNG del sistema rispetto allo scenario accademico puramente teorico che "entropy_avail" tenta di acquisire (e in realtà non riesce).