Quanto è pessimo alimentare / dev / random con / dev / urandom?

Sto presupponendo un sistema Linux qui, su alcuni sistemi operativi come FreeBSD e Mac OS non c'è alcuna differenza tra /dev/random e /dev/urandom , e altri ancora non hanno quei dispositivi

Sia /dev/random che /dev/urandom utilizzano lo stesso pool di entropia. La differenza è che / dev / random "conta" quanti byte sono stati estratti, stimando l'entropia rimasta nel pool. Se a un certo punto considera che non c'è abbastanza entropia per ciò che viene chiesto, bloccherà, mentre /dev/urandom fornirà i byte richiesti.

Il fatto è che solo /dev/urandom sarebbe stato perfettamente soddisfacente (tranne poco dopo l'avvio) . L'alimentazione di /dev/random con /dev/urandom è un modo di barare, ma in realtà non dovrebbe inficiare la sicurezza.

do I need to invalidate tls certificates, ssh and gpg keys right know, like with the infamous debian bug CVE-2008-0166 ?

Assolutamente no.

Or is it more like a state-sponsored attacker may find my private key given a few billion euros

Anche per un aggressore sponsorizzato dallo stato, non penso che non sarebbe fattibile calcolare i byte casuali estratti dal pool casuale su un sistema normale.

L'eccezione sono i dispositivi incorporati, come i router, in cui troppo spesso si trovano a generare una chiave casuale (ad esempio per https o ssh) poco dopo l'avvio, dove in realtà hanno uno stato abbastanza deterministico.

Tuttavia, per le chiavi a lungo termine come quelle che hai citato, potresti comunque preferire il feed da /dev/random , sapendo che ci vorrà più tempo, e basta evitare l'utilizzo di /dev/urandom . E va bene anche.

È una cosa stupida da fare, ma non è pericoloso.

Il motivo è che Linux è conservativo e considera i dati che si alimentano in /dev/random come deterministici, quindi non aumenta la sua stima di entropia interna.

Dalla pagina man :

Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

Quindi, copiare byte da /dev/urandom a /dev/random solo spreca CPU ma non è pericoloso. Se vedi che viene fatto su un server, non devi preoccupartene di per sé. La cosa più preoccupante a riguardo è probabilmente che è un indizio che il server sia stato creato da una persona che crede in olio di serpente per sicurezza o, peggio, cerca di aggirare le caratteristiche di sicurezza che sono state messe in atto per un motivo. Anche se quest'ultimo non avrebbe funzionato in questo caso. ¹ Quindi forse controlla se ci sono altre cose sul server che potrebbero essere meno buone.

D'altro canto, la lettura da /dev/random potrebbe effettivamente essere utile in uno script di avvio perché bloccherà fino a quando il sistema non avrà raccolto abbastanza entropia nel suo pool interno per rendere /dev/urandom sicuro da usare.

¹ Se vuoi davvero essere cattivo e rendere /dev/random non bloccante anche se il kernel ha stimato che è basso su entropy, potresti semplicemente renderlo un alias per /dev/urandom .

# rm -f /dev/random
# mknod -m 0666 /dev/random c 1 9

Vedi la pagina man per mknod e guarda l'output di

$ stat /dev/random /dev/urandom

se sei confuso su cosa sta succedendo qui. (Il comando stat è sicuro da eseguire.)

Consiglio vivamente contro brutti scherzi come questo, ovviamente.

Proverò a rispondere a una domanda semplificata: esiste un attacco fattibile su un vero CSPRNG (generatore di numeri casuali crittograficamente sicuro)? E poi, e se non fosse un CSPRNG perfetto?

caso 1)

Per semplificare le cose, supponiamo che non venga aggiunta entropia dopo l'impostazione di inizializzazione di un CSPRNG vero e deterministico. Inoltre, non assumere alcuna perdita di informazioni nell'inizializzazione.

Da wikipedia la definizione di CSPRNG è data come segue:

Every CSPRNG should satisfy the next-bit test. That is, given the first k bits of a random sequence, there is no polynomial-time algorithm that can predict the (k+1)th bit with probability of success non-negligibly better than 50%. Andrew Yao proved in 1982 that a generator passing the next-bit test will pass all other polynomial-time statistical tests for randomness.

Every CSPRNG should withstand "state compromise extensions". In the event that part or all of its state has been revealed (or guessed correctly), it should be impossible to reconstruct the stream of random numbers prior to the revelation. Additionally, if there is an entropy input while running, it should be infeasible to use knowledge of the input's state to predict future conditions of the CSPRNG state.

Ciò significa che anche se parte della sequenza di output casuale è trapelata, le parti della sequenza prima e dopo quella parte trapelata non possono essere determinate.

In questo caso sei completamente sicuro usando /dev/urandom , anche se c'è una perdita dei dati della sequenza casuale e anche se non sono mai aggiunti dati casuali esterni alla sequenza dopo l'inizializzazione.

caso 2)

Supponiamo che il cosiddetto CSPRNG sia effettivamente rotto. Proprio per la vendita di argomentazioni supponiamo che data una perdita parziale della sequenza, sia le parti passate che quelle future della sequenza "abbastanza vicine" alla perdita siano severamente compromesse.

In un caso CSPRNG rotto, l'entropia aggiunta aggiungerà sicurezza al sistema. Se 256 veri bit di entropia separano la perdita e un numero casuale X usato per uno scopo critico, allora lo spazio di ricerca per un attacco su X viene ingrandito di 2 ^ 256 - ed è quindi totalmente sicuro.

Quindi il caso 2 è un rischio nelle seguenti 2 condizioni:

1. C'è una perdita dello stato della sequenza casuale.
2. Il PRNG non è un CSPRNG perfetto.

Ma garantire una sufficiente entropia può mitigare perfettamente il rischio.

Riguardo alla condizione (1): la possibilità di una perdita di dati. Alcune implementazioni Java forniscono accesso ai dati sottostanti / dev / random. Lo dice nella documentazione di Java.

È fantastico per la scelta di numeri casuali in Java, ma potrebbe essere utilizzato dal malware basato su Java per divulgare informazioni sulla sequenza casuale. Oltre a Java, ogni volta che crei una password casuale con il tuo software e la trasmetti a un sito web esterno, questo potrebbe far trapelare alcune informazioni sullo stato della sequenza casuale.

Riguardo alla condizione (2): mentre può essere possibile dimostrare che un particolare PRNG è non un CSPRNG, non è possibile dimostrare che un particolare PRNG è un CSPRNG. Devi solo sperare che il CSPRNG non sia stato smentito senza che tu te ne accorga. Ci sono anche sfumature di grigio: un attacco particolare apre solo una stretta finestra di vulnerabilità prima e dopo una perdita, e richiederebbe enormi risorse per sfruttarlo. Valutare il rischio di un attacco sconosciuto (a voi) con un numero concreto è difficile o impossibile, ma trattare il rischio come una variabile sconosciuta ed esaminare il costo della mitigazione rispetto alle conseguenze poiché il rischio varia è un esercizio significativo.

Nota: c'è una domanda per un laico: se il PRNG è deterministico, come può il prossimo bit non essere prevedibile se si verifica una perdita? La risposta è che sebbene l'algoritmo di sequenza casuale generale sia di per sé noto, la funzione utilizzata per la transizione da una coppia (valore, stato) alla successiva (valore, stato) coppia viene inizialmente scelta da una vasta famiglia di funzioni, ad esempio una di 2 ^ 256 di tali funzioni. Quindi è possibile utilizzare altri 256 bit per inizializzare la funzione scelta. (In realtà sono necessari solo 128 bit per inizializzare la sequenza /dev/random ).