Se è vero, hai bisogno di circa 128 bit di entropia per alimentare sempre abbastanza dati, perché è così lento / dev / random? Il mio sistema ha uptime di 214 giorni!
In realtà, raccoglie solo 0,000000001 bit di entropia ogni campione? Non dovrebbe un semplice jitter che legge dal kernel fornire almeno 1 bit di entropia? Non è stato il campionamento per gli ultimi 214 giorni?
Si tratta di un errore di progettazione colossale o mi manca qualcosa?
BTW, ritengo che questo sia più un problema di sicurezza IT o di sistema operativo Linux rispetto alla crittografia.
Un problema con Linux / dev / urandom è che non è possibile testare se è stato seminato correttamente. Il generatore di numeri casuali può restituire valori basati su un'entropia insufficiente.
Pertanto, molti girano a / dev / random. Tuttavia, vi sono differenze significative tra le implementazioni / dev / random su diversi sistemi (o cloni) conformi a POSIX. Su FreeBSD, / dev / random funziona come / dev / urandom su Linux. Mac OS X è simile a FreeBSD in molte cose e anche qui: / dev / random è come / dev / urandom.
L'obiettivo di Linux / dev / random è di restituire sostanzialmente l'entropia completa (un bit di output contiene un bit di entropia). L'approccio a questo obiettivo è stimare la quantità di entropia raccolta e utilizzare quella stima e raccogliere il materiale di entropia per produrre output. Senza il supporto di Linux disponibili fonti di entropia basate su hw, i meccanismi di raccolta di entropia di base raccoglieranno l'entropia abbastanza lentamente.
Ci sono alcuni modi per accelerare la raccolta di entropia, tra cui:
Se il / dev / random è vuoto dopo un lungo periodo di operatività della macchina, significa che alcune applicazioni hanno utilizzato i dispositivi randomness. In Linux, / dev / random considera che la stessa quantità di entropia viene persa dal pool di entropia rispetto alla quantità totale di bit richiesti. (Ad esempio, anche se linux ha 4096 bit completi nel pool di entropia, non richiede ancora molte richieste di dire 128 o 256 bit per esaurire il pool). Occasionalmente il pool è esaurito perché alcune applicazioni usano male / dev / random. Alcune applicazioni potrebbero tentare di leggere grandi quantità di dati, ad esempio 2048 bit.
Per farla breve, dovresti leggere la pagina man appropriata (man 4 random), e decidere se / dev / random o / dev / urandom è effettivamente ciò di cui hai bisogno. Se mac / dev / random sarebbe ok per te, è probabile che saresti felice con / dev / urandom. La ragione per cui la generazione di numeri casuali è apparso da / dev / random molto più velocemente su Mac è che su Mac / dev / random indica qualcosa di diverso da / dev / random su Linux. Infine, ma non meno importante, vorrei dire: mi piace il fatto che Linux offra due semantiche diverse, sistemi operativi in cui / dev / urandom e / dev / random sono la stessa offerta molto meno scelta.
Direi che questo non è un errore colossale, il design è solo un po 'strano dal punto di vista di molti. Una volta che hai familiarità con il design e le restrizioni e sai come usare i dispositivi, il design sembra abbastanza buono.
(A proposito, altri sistemi come NetBSD hanno ancora una semantica leggermente diversa per / dev / random e / dev / urandom.)
Leggi altre domande sui tag entropy