È sbagliato collegare / dev / random a / dev / urandom su Linux?

Attualmente sto testando gpg --genkeysu una macchina virtuale Linux. Sfortunatamente, questo software sembra fare affidamento /dev/randomper raccogliere l'entropia e chiede educatamente all'utente di digitare manualmente schermate dopo schermate di input crittograficamente casuali in modo che alla fine possa finire con la generazione di una chiave, e non ho trovato alcun parametro della riga di comando da dire per usare un altro file come fonte entropica (il ragazzo in questo video incontra lo stesso problema ...).

Tuttavia, l'utente dovrebbe essere libero di scegliere di utilizzare /dev/urandominvece poiché non c'è nulla di sbagliato in esso . È presente principalmente come reminescenza di vecchi algoritmi PRNG che erano più deboli dal punto di vista crittografico. Ad esempio, sebbene la manpage di NetBSD garantisca che la distinzione possa ancora essere utile nelle prime fasi di avvio, descrive tale distinzione come "folklore" e una "teoria immaginaria che si difende solo contro i modelli di minaccia fantasy" . Nessuno concorda con la quantità di entropia richiesta da questo comando né con il fatto che l'entropia sia qualcosa che viene effettivamente consumato come indicato nella manpage GPG ("PER FAVORE, non usare questo comando se non sai cosa stai facendo, potrebbe rimuovere preziose entropie dal sistema!" ).

Ho letto di persone che installano il rngddemone e lo configurano per usarlo /dev/urandomcome fonte di entropia per alimentare /dev/random, ma trovo questa pratica molto sporca.

Ho provato a risolvere il problema nel modo FreeBSD rimuovendolo /dev/randome collegandolo /dev/urandominvece:

rm /dev/random
ln -s /dev/urandom /dev/random

Vedo questo come un'ambientazione che dice "Mi fido della /dev/urandomfonte dell'entropia" .

Temevo che avrei riscontrato qualche errore di qualche tipo, ma questo sembra fornire il risultato atteso poiché il comando ora restituisce immediatamente con successo.

La mia domanda è: c'è qualche nota, pratico e sbagliato effetto collaterale di collegare /dev/randoma /dev/urandomsu sistemi Linux come fatto per impostazione predefinita sui sistemi FreeBSD? O si potrebbe pensare di impostarlo permanentemente (ad esempio in uno script alla fine del processo di avvio) in caso di problemi ripetitivi dovuti al /dev/randomblocco di alcuni servizi?

Vedi Miti su urandom , non esiste alcun attacco noto su / dev / urandom che non sia un attacco su / dev / random. Il problema principale che ha un sistema Linux è quando viene clonato ed eseguito come più macchine virtuali senza ripristinare il pool di entropia salvato dopo la clonazione. Questo è un caso angolare tangenziale a ciò che vuoi.

Bene, una cosa diversa /dev/randomè che interrompe l'output dopo l'utilizzo del pool di entropia. prova questo:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/dev/urandomtuttavia riutilizzerà lo stesso pool per continuare l'output. come mostrato qui:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Quando si tenta di cat questi dispositivi speciali, il prompt potrebbe essere incasinato. Basta digitare reseted entrare, il terminale tornerà alla normalità)

Utilizzare /dev/urandomquando è sufficiente riempire qualcosa con un flusso costante di bit "casuali". Utilizzare /dev/randomper le chiavi che è necessario essere assolutamente casuali.

In Linux, /dev/randomfornisce bit casuali di alta qualità. Sono derivati ​​da fonti non prevedibili e non ripetibili, esterne alla macchina. Al contrario, /dev/urandomutilizza gli stessi dati casuali di /dev/random(se disponibili), se non ce ne sono, utilizza un generatore di numeri pseudo-casuale, che è deterministico . Per la maggior parte degli scopi, è abbastanza imprevedibile, ma non per applicazioni molto impegnative come la crittografia, e tanto meno per la creazione di chiavi di lunga durata come per GPG.