Quando usare /dev/random vs /dev/urandom?

Dovrei usare /dev/random o /dev/urandom ?

In quali situazioni preferirei uno rispetto all'altro?

Risposta accettata:

TL;DR

Usa /dev/urandom per la maggior parte degli scopi pratici.

La risposta più lunga dipende dal tipo di Unix che stai utilizzando.

Linux

Storicamente, /dev/random e /dev/urandom sono stati introdotti contemporaneamente.

Come ha sottolineato @DavidSchwartz in un commento, usando /dev/urandom è preferito nella stragrande maggioranza dei casi. Lui e altri hanno anche fornito un collegamento agli eccellenti miti su /dev/urandom articolo che consiglio per ulteriori letture.

In sintesi:

• La pagina di manuale è fuorviante.
• Entrambi sono alimentati dallo stesso CSPRNG per generare casualità (schemi 2 e 3)
• /dev/random si blocca quando esaurisce l'entropia,
  quindi leggendo da /dev/random può interrompere l'esecuzione del processo.
• La quantità di entropia è stimata in modo prudente, ma non conteggiata
• /dev/urandom non bloccherà mai.
• In rari casi, subito dopo l'avvio, il CSPRNG potrebbe non aver avuto abbastanza entropia per essere correttamente seminato e /dev/urandom potrebbe non produrre una casualità di alta qualità.
• L'entropia in esaurimento non è un problema se il CSPRNG è stato inizialmente seminato correttamente.
• Il CSPRNG viene costantemente reinseminato.
• In Linux 4.8 e versioni successive, /dev/urandom non esaurisce il pool di entropia (usato da /dev/random ) ma utilizza l'output CSPRNG dall'upstream.
• Usa /dev/urandom .

Eccezioni alla regola

In Cryptography Stack Exchange Quando usare /dev/random su /dev/urandom in Linux @otus fornisce due casi d'uso:

1. Poco dopo l'avvio su un dispositivo a bassa entropia, se non è stata ancora generata abbastanza entropia per eseguire correttamente il seeding di /dev/urandom .

2. Generazione di un one-time pad con sicurezza informatica

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 si bloccherà, ma fai attenzione alle possibili condizioni di gara.

Alternativa:non utilizzare nessuno dei due!

@otus ha anche sottolineato che getrandom() il sistema leggerà da /dev/urandom e si blocca solo se l'entropia seed iniziale non è disponibile.

Ci sono problemi con la modifica di /dev/urandom per usare getrandom() , ma è ipotizzabile che un nuovo /dev/xrandom il dispositivo viene creato in base a getrandom() .

macOS

Non importa, come dice Wikipedia:

macOS utilizza Yarrow a 160 bit basato su SHA1. Non c'è differenza tra /dev/random e /dev/urandom; entrambi si comportano in modo identico. Anche iOS di Apple utilizza Yarrow.

FreeBSD

Non importa, come dice Wikipedia:

/dev/urandom è solo un collegamento a /dev/random e blocca solo fino a quando non viene seminato correttamente.

Ciò significa che dopo l'avvio, FreeBSD è abbastanza intelligente da attendere che sia stata raccolta una quantità sufficiente di entropia del seme prima di fornire un flusso infinito di bontà casuale.

Correlati:Linux – Come far funzionare Oracle java 7 con setcap cap_net_bind_service+ep?

NetBSD

Usa /dev/urandom , supponendo che il tuo sistema abbia letto almeno una volta da /dev/random per garantire una corretta semina iniziale.

La manpage di rnd(4) dice:

/dev/urandom non si blocca mai.

/dev/random a volte blocca. Si bloccherà presto all'avvio se è noto che lo stato del
è prevedibile.

Le applicazioni devono essere lette da /dev/urandom quando hanno bisogno di dati generati casualmente
, ad es. chiavi crittografiche o semi per simulazioni.

I sistemi dovrebbero essere progettati per leggere con giudizio almeno una volta da /dev/random all'avvio prima di eseguire qualsiasi servizio che dialoga con
Internet o che richieda in altro modo la crittografia, al fine di evitare
di generare chiavi in ​​modo prevedibile.