Aggiungi un file come sorgente di entropia per / dev / random

Prima di tutto, per rispondere direttamente alla tua domanda: Questo non può essere fatto. È intenzionalmente non consentito.

Puoi, in effetti, scrivere su / dev / random e mescolerà il tuo input nel pool casuale, migliorando potenzialmente la qualità dell'output. Ma non aggiornerà entropy_count e sbloccherà / dev / random per la lettura, perché sarebbe barare . Altrimenti saresti in grado di fare qualcosa del genere:

cat /dev/urandom > /dev/random  # Sup dawg, I heard you like random pools...

Tranne che puoi. Sort of.

C'è un ioctl chiamato RNDADDENTROPY disponibile su / dev / random che aggiorna il pool entropico e quindi incrementa di conseguenza il conto entropy. L'idea è di consentire di leggere da un RNG hardware nello userspace e di riversarlo nel pool del kernel senza scrivere il proprio driver. Nifty. E mentre a chiunque è permesso di scaricare la loro entropia in / dev / random (non può offendere ), solo a root è permesso usare RNDADDENTROPY .

E sì, c'è uno strumento là fuori che ti permette di farlo con relativa facilità; si chiama rngd . Il suo scopo principale è quello di leggere da un RNG come /dev/hwrandom o l'istruzione RDRAND del processore, e ri-seminare costantemente il tuo pool entropico man mano che si abbassa. Ma ci vuole un nome di file arbitrario per l'input, quindi sì, puoi anche farlo:

rngd -r /dev/urandom

Che, in tutta onestà, non è del tutto diverso da questo:

ln -sf /dev/urandom /dev/random

Ma come ho affermato in origine, ciò non significa che tu possa usare questo strumento per far sì che il del kernel usi il tuo file come fonte di entropia. Quel bit, almeno, non è permesso. Puoi usarlo come un'ulteriore fonte di entropia mescolata con tutte le altre, ma non l'unica fonte di entropia.

Se sei convinto che il tuo file sia di una casualità di prim'ordine, usa solo quello. Non devi dover iniettarlo attraverso il sistema di stima dell'entropia del kernel. Se invece disponi di un meccanismo per generare TRNG, allora in ogni caso lo scarichi lì con tutto il resto delle fonti di entropia; rngd lo rende piuttosto semplice.

Non mi preoccuperò di parlarti della totale assurdità di evitare religiosamente / dev / urandom sui server reali, come chiaramente hai sentito quella conferenza più volte e hai scelto di non ascoltare.

Ma per tutti gli altri, la differenza tra / dev / random e / dev / urandom conta solo immediatamente all'avvio su dispositivi senza fonti ragionevoli di casualità (come alcuni dispositivi embedded), dove le condizioni di avvio sono precisamente ripetibili e dove il pool casuale non viene salvato tra gli stivali. In tutti gli altri casi, qualsiasi attacco teorico contro / dev / urandom richiederebbe tecniche e tecnologia che letteralmente non esistono, e non ci si aspetta che mai esisteranno mai.

Dal testo della tua domanda, sembra che tu abbia l'impressione che / dev / random generi il risultato di un TRNG, mentre / dev / urandom usa un PRNG. Questo non è accurato. L'unica differenza nell'output è che random "si bloccherà" se sta generando byte più velocemente di quanto non stia osservando eventi casuali, mentre urandom non lo farà. In caso contrario, eseguono entrambi lo stesso codice nei rispettivi pool. Né emette direttamente i bit grezzi da un TRNG. Entrambi utilizzano eventi casuali per ri-seminare costantemente un PRNG.

Dato tutto ciò che hai detto, dovresti probabilmente leggere direttamente dal tuo file invece che da / dev / random. Dato che apparentemente non ti fidi di come funziona / dev / random (forse leggi questo documento ), allora sii dichiarativo, e non fidarti di questo.

A questo punto dovresti capire che non dovrebbe esserci modo che qualcuno possa essere autorizzato a iniettare dati direttamente nel pool di entropia. Altrimenti sarebbe un vettore di attacco che potrebbe compromettere la generazione di chiavi SSL / TLS, e tutti i cattivi lo farebbero già.

Se insisti a proseguire, controlla come gli strumenti rng inseriscono i dati nel pool di entropia. È progettato per integrare l'output di un RNG hardware e puoi modificarlo per leggere dal tuo file anziché da un dispositivo hardware. La mia preoccupazione è che anche se fornisci abbastanza dati dal tuo file, / dev / random potrebbe bloccarsi se non ottiene abbastanza entropia dalle sue altre fonti. Non si suppone che abbia tutti i suoi entropy bit da una singola fonte, quindi non importa quanto velocemente li fornisci, penso che potrebbe bloccarli.

Se stai usando un vero generatore di numeri casuali dell'hardware per creare i tuoi file, prenderei in considerazione l'uso di rng-tools per legarlo direttamente al pool di entropia senza il passaggio intermedio del commit al file system.

La cosa bella di questo approccio è che riduce il rischio che il tuo file sia un'influenza corruttrice su numeri casuali (i dati sono mescolati con altre fonti di entropia) e riduce il rischio che un utente malintenzionato copi il tuo file e apprenda il tuo numeri casuali (dovuti alle altre fonti di entropia).

Sulla maggior parte dei sistemi Linux, il pool di entropia utilizzato da / dev / random è inizializzato all'avvio utilizzando /var/run/random-seed . Se questo processo è stato omesso, due server identici che utilizzano la stessa distribuzione di Linux potrebbero avere una sequenza di avvio identica e quindi disporre di uno stato identico / dev / random.

Per evitare che ciò accada, al momento dell'arresto il valore corrente del pool di% entalute% co_de viene salvato in /dev/random e quindi ripristinato all'avvio. Fare in modo che l'entropia di tutti diventi un po 'diversa, il che è un grande design.

Aumentare il contatore di entropia del kernel richiede RNDADDENTROPY ioctl.

Il modo più semplice per chiamarlo è utilizzare il daemon rngd dal pacchetto rng-tools :

rngd -r /path/to/F

(Nota: rngd si aspetta che questo sia un dispositivo hardware, quindi quando raggiunge la fine del file, si lamenterà che la fonte di entropia non funziona più.)