Dovrei usare /dev/randomo /dev/urandom?
In quali situazioni preferirei l'uno all'altro?
Risposte:
Utilizzare /dev/urandomper scopi più pratici.
La risposta più lunga dipende dal sapore di Unix in esecuzione.
Storicamente, /dev/randome /dev/urandomsono stati entrambi introdotti allo stesso tempo.
Come ha sottolineato @DavidSchwartz in un commento , l'uso /dev/urandomè preferito nella stragrande maggioranza dei casi. Lui e altri hanno anche fornito un link agli eccellenti Miti/dev/urandom sull'articolo che raccomando per ulteriori letture.
In sintesi:
/dev/random si blocca quando si esaurisce l'entropia/dev/urandomnon si bloccherà mai, la lettura da /dev/randompuò interrompere l'esecuzione dei processi./dev/urandompotrebbe non produrre casualità di alta qualità./dev/urandomnon esaurisce il pool di entropia (utilizzato da /dev/random) ma utilizza l'output CSPRNG dall'upstream./dev/urandom.Eccezioni alla regola
Nella crittografia del Stack di Exchange Quando usare /dev/randomoltre /dev/urandoma Linux
@otus dà due casi di utilizzo :
Poco dopo l'avvio su un dispositivo a bassa entropia, se non è stata ancora generata abbastanza entropia per eseguire correttamente il seeding /dev/urandom.
Generare un pad unico con sicurezza teorica delle informazioni
Se sei preoccupato per (1), puoi controllare l'entropia disponibile in/dev/random .
Se stai facendo (2) lo saprai già :)
Nota: puoi verificare se la lettura da / dev / random bloccherà , ma fai attenzione alle possibili condizioni di gara.
Alternativa: non usare nessuno dei due!
@otus ha anche sottolineato che il getrandom()sistema leggerà /dev/urandome bloccherà solo se l'entropia iniziale del seme non è disponibile.
Ci sono problemi con il cambio /dev/urandomda usaregetrandom() , ma è concepibile che un nuovo /dev/xrandomdispositivo sia creato sulla base getrandom().
Non importa, come dice Wikipedia :
MacOS usa 160 bit Yarrow basato su SHA1. Non vi è alcuna differenza tra / dev / random e / dev / urandom; entrambi si comportano in modo identico. L'iOS di Apple utilizza anche Yarrow.
Non importa, come dice Wikipedia :
/dev/urandomè solo un collegamento/dev/randome blocca solo fino a quando non viene eseguito correttamente il seeding.
Ciò significa che dopo l'avvio, FreeBSD è abbastanza intelligente da aspettare fino a quando non è stata raccolta abbastanza entropia da seme prima di fornire un flusso infinito di bontà casuale.
Utilizzare /dev/urandom, supponendo che il sistema abbia letto almeno una volta da /dev/randomper garantire il seeding iniziale corretto.
La manpage rnd (4) dice :
/dev/urandomNon blocca mai.
/dev/randomA volte blocchi. Si bloccherà presto all'avvio se è noto che lo stato del sistema è prevedibile.Le applicazioni dovrebbero leggere da / dev / urandom quando necessitano di dati generati casualmente, ad esempio chiavi crittografiche o seed per simulazioni.
I sistemi dovrebbero essere progettati per leggere giudiziosamente almeno una volta da / dev / random all'avvio prima di eseguire qualsiasi servizio che parli su Internet o che altrimenti richiedano la crittografia, al fine di evitare di generare le chiavi in modo prevedibile.
/dev/urandom - Tranne che /dev/urandomsu OpenBSD non esiste nulla come . OpenBSD ha /dev/arandom, ma non dovresti usarlo, dovresti invece usare la arc4random(3)funzione. Forse consigli su dispositivi e funzioni casuali dovrebbero essere lasciati a persone che capiscono davvero di cosa si tratta?
/dev/randomblocca quando si esaurisce l'entropia" - Su Linux, dipende da come si apre il dispositivo. Se le openbandiere includono O_NONBLOCKallora non si bloccherà. Se non c'è entropia, la chiamata tornerà immediata e indicherà 0 byte letti.
/dev/randomè solo (es. 60 byte, ddti darà un file di 60 byte. L'uso headnello stesso scenario probabilmente sembrerà sospeso per sempre. Né sta facendo quello che vuoi, ma, almeno per me, è più ovvio che headnon sta facendo quello che ci si aspettava.
Tradizionalmente, l'unica differenza tra /dev/urandomed /dev/randomè ciò che accade quando il kernel pensa che non ci sia entropia nel sistema - /dev/randomfallisce chiuso, /dev/urandomfallisce aperto. Entrambi i piloti sono stati riforniscono entropia da add_disk_randomness(), add_interrupt_randomness()e add_input_randomness(). Vedi /drivers/char/random.cper i dettagli.
Modificato per aggiungere: A partire da Linux 4.8 è /dev/urandomstato rielaborato per utilizzare CSPRNG.
Quindi quando non dovresti chiudere? Per qualsiasi tipo di uso crittografico, in particolare il seeding di DRBG. C'è un ottimo documento che spiega le conseguenze dell'uso /dev/urandomquando si generano chiavi RSA e non si ha abbastanza entropia. Leggi il mining di Ps e Qs .
Questa è in qualche modo una risposta "anch'io", ma rafforza la raccomandazione di Tom Hale. Si applica esattamente a Linux.
/dev/urandom/dev/randomSecondo Theodore Ts'o nella mailing list di Linux Kernel Crypto, /dev/randomè stato deprecato per un decennio. Da Re: [RFC PATCH v12 3/4] Generatore di numeri casuali Linux :
Praticamente nessuno usa / dev / random. È essenzialmente un'interfaccia deprecata; le interfacce primarie consigliate da oltre un decennio sono / dev / urandom e ora getrandom (2).
Testiamo regolarmente /dev/randome subisce frequenti guasti. Il test esegue i tre passaggi: (1) svuotamento /dev/randomchiedendo 10K byte in modalità non bloccante; (2) richiesta 16 byte in modalità blocco (3) tenta di comprimere il blocco per vedere se è casuale (test da povero). Il completamento del test richiede minuti.
Il problema è così grave sui sistemi Debain (i686, x86_64, ARM e MIPS) che abbiamo chiesto a GCC Compile Farm di installare il rng-toolspacchetto per le loro macchine di prova. Da Installa rng-tools su gcc67 e gcc68 :
Vorrei richiedere l'installazione di rng-tools su gcc67 e gcc68. Sono sistemi Debian e / dev / random subisce l'esaurimento dell'entropia senza rng-tools quando torturano le librerie di test che utilizzano il dispositivo.
I BSD e OS X sembrano OK. Il problema è sicuramente Linux.
Potrebbe anche valere la pena ricordare che Linux non registra i guasti del generatore. Non volevano che le voci riempissero il registro di sistema. Ad oggi, la maggior parte degli errori è silenziosa e non viene rilevata dalla maggior parte degli utenti.
La situazione dovrebbe cambiare a breve poiché il kernel stamperà almeno un messaggio di errore. Da [PATCH] random: mette in silenzio gli avvisi del compilatore e corregge la gara sulla mailing list crittografica del kernel:
In particolare, ho aggiunto
depends on DEBUG_KERNEL. Questo significa che questi utili avvertimenti stimoleranno solo altri sviluppatori del kernel. Questo è probabilmente esattamente quello che vogliamo. Se i vari sviluppatori associati vedono un avviso proveniente dal loro particolare sottosistema, saranno più motivati a risolverlo. Gli utenti ordinari sui kernel di distribuzione non dovrebbero vedere affatto gli avvisi o lo spam, poiché in genere gli utenti non utilizzano DEBUG_KERNEL.Penso che sia una cattiva idea sopprimere tutti i messaggi dal punto di vista dell'ingegneria della sicurezza.
Molte persone non eseguono kernel di debug. La maggior parte degli utenti che vogliono o hanno bisogno di conoscere i problemi non si accorgeranno che sta accadendo. Considera, il motivo per cui abbiamo appreso dei problemi di Systemd era dovuto a Dmesg.
La soppressione di tutti i messaggi per tutte le configurazioni genera una rete più ampia del necessario. Le configurazioni che potrebbero essere potenzialmente rilevate e risolte probabilmente passeranno inosservate. Se il problema non viene portato alla luce, non verrà risolto.
Sento che il kernel sta prendendo decisioni politiche per alcune organizzazioni. Per coloro che dispongono di hardware effettivamente non risolvibile, l'organizzazione deve decidere cosa fare in base alla propria avversità al rischio. Potrebbero decidere di convivere con il rischio o potrebbero decidere di aggiornare l'hardware. Tuttavia, senza informazioni sul problema, potrebbero anche non rendersi conto di avere un oggetto utilizzabile.
Il compromesso eventualmente raggiunto in seguito nel thread era almeno un dmesg per modulo chiamante.