In generale:
-
/dev/urandom non è meno sicuro di /dev/random . Infatti usano entrambi gli stessi algoritmi e gli stessi semi. Occasionalmente, /dev/random si interrompe solo perché qualcuno, un giorno, legge qualcosa sull'entropia, non lo capisce, e ora pensa che la casualità sia qualcosa che viene bruciata dopo l'uso e deve essere ricaricata regolarmente.
( Questa pagina fa un buon lavoro spiegando le cose a riguardo.)
-
Ci possono essere situazioni in cui non c'è abbastanza entropia disponibile nell'intero sistema. Queste situazioni non si verificano con le normali distribuzioni Linux perché generano e salvano un seed casuale all'avvio, da utilizzare per il successivo avvio, garantendo in modo efficace che /dev/urandom sia crittograficamente sicuro per tutto il tempo. Per entrare in una di queste situazioni, devi giocare qualche gioco strano con le istantanee VM, o usare non un PC ma un sistema embedded molto limitato; questo è abbastanza lontano dai contesti in cui useresti GnuPG.
-
È molto degno di nota il fatto che nel caso delle istantanee VM, la "stima dell'entropia" di /dev/random riporti allegramente che è piena di cose, che in questo caso è molto sbagliato. Cioè, non solo il comportamento di blocco di /dev/random è scientificamente infondato, ma anche non riesce a essere innescato in un caso pratico (snapshot della VM) dove si poteva temere la perdita di entropia.
-
Ricorda inoltre che i contesti in cui /dev/urandom è inappropriato sono contesti anche in cui /dev/random è inappropriato. Usare /dev/random non renderà le cose "più casuali"; nella migliore delle ipotesi , si rifiuterà di lavorare invece di generare una chiave di sicurezza teoricamente inferiore ("teoricamente" perché nessuno di questi ha mai portato a una rottura pratica, nemmeno come dimostrazione in condizioni controllate dal laboratorio) . Come spiegato sopra, questo è davvero un "al massimo" e in realtà non funzionerà in questo modo con le istantanee VM e resettato.
Fortunatamente, tutte le attività coinvolte da un avvio implicano la raccolta di sufficiente entropia per raggiungere la sicurezza crittografica (anche per uscite arbitrariamente lunghe di /dev/urandom , pari). Vedi questo articolo per ulteriori analisi. La generazione della chiave GnuPG non viene eseguita dal kernel nelle prime fasi di avvio; si verifica molto più tardi, durante il normale funzionamento, quando il PRNG è stato seminato correttamente.
Niente di tutto ciò impedisce ad alcune persone di insistere su danze rituali con entropia. Apparentemente, gli autori di GnuPG fanno parte di quella specifica interpretazione teologica - o perché ci credono o perché cedono sotto la pressione del mercato.
Riepilogo: utilizzando /dev/urandom anziché /dev/random è non debole per GnuPG. GnuPG è usato in un contesto in cui /dev/urandom è correttamente seminato e raggiungerà tutta l'imprevedibilità richiesta, e /dev/random non farà di meglio (non nella pratica, nemmeno in teoria). Nell'unica situazione (istantanee VM) in cui l'output di /dev/urandom potrebbe essere inadeguato per GnuPG, l'output di /dev/random sarà ugualmente inadeguato per gli stessi motivi e il meccanismo di blocco di /dev/random non verrà attivato. La conclusione è che passare da /dev/urandom a /dev/random per GnuPG è completamente inutile .
... cioè, da un punto di vista tecnico. L'utilizzo di /dev/random anziché /dev/urandom potrebbe indurre qualche blocco che può aiutare a persuadere gli utenti con una mente debole che "sta accadendo una seria crittografia". Non renderà le cose più sicure, ma potrebbe rendere l'utente sentirsi più sicuro.