Pseudo Random Generator non è inizializzato dal (entropy pool)?

/ dev / urandom sempre tenterà di restituire il valore più casuale possibile. Nel peggiore dei casi, utilizzerà la crittografia per "allungare" gli ultimi bit di entropia nel pool per soddisfare la richiesta. Al contrario / dev / random bloccherà fino a quando il pool di entropia sarà abbastanza pieno da riempire i byte richiesti, quindi / dev / random garantirà un valore più casuale . Tuttavia / dev / random bloccherà fino a quando l'archivio entropico non sarà abbastanza grande da riempire i byte richiesti, il che è inaccettabile in quasi tutti gli usi. Se il pool di entropia è pieno, quindi / dev / urandom e / dev / random sono identici .

Quando rc.sysinit si spegne copia 512 byte da /dev/urandom . A questo punto è probabile che la macchina sia attiva da un po 'di tempo, quindi il pool di entropia ha avuto la possibilità di riempire. Lì per questo file è molto probabilmente un pezzo puro del pool di entropia. Tuttavia, se il pool di entropia non è pieno, è meglio avere qualcosa di niente (o, peggio ancora, bloccare fino a quando il pool di entropia è pieno abbastanza prima di spegnersi).

Su un sistema Linux è molto importante che il pool entropico venga popolato durante l'avvio. Per soddisfare questa necessità, l'azione shutdown è di salvare il pool entropy su disco e l'avvio è di ricaricare questo entropy pool molto presto nel processo di avvio. Su un sistema Linux, le locazioni di memoria ASLR e i valori di sequenza TCP vengono calcolati con questo pool di entropia. Se il pool è stato svuotato, allora su ogni avvio il layout dello spazio di memoria dei processi demone non sarebbe molto casuale e lì per un processo come il demone SMTP potrebbe essere sfruttato più facilmente tramite un buffer overflow. Ciò influisce anche sulla tua suscettibilità agli attacchi MITM. Questo perché sarebbe più facile per un utente malintenzionato prevedere i valori della sequenza TCP necessari per completare l'handshake TCP a 3 vie.

Se vedi una distribuzione Linux che non ripristina non è entropy pool all'avvio, allora la sua vulnerabilità che deve essere segnalata .

Se desideri maggiori informazioni, prova a leggere i commenti del codice in random.c

Permettetemi di integrare le altre risposte spiegando, con un certo livello di dettaglio, come funziona un PRNG con un pool di entropia. Questa è una semplificazione eccessiva, poiché l'attuale implementazione di Linux utilizza più pool. Ma dovrebbe aiutarti a darti un'idea di base su come funziona lo schema.

In primo luogo, contiene tre parti chiave:

1. Un pool di entropia. Questo è fondamentalmente solo una serie di byte. Un obiettivo chiave del sistema è garantire che un utente malintenzionato non conosca questi byte.

2. Un PRNG. Questo è un componente algoritmico che opera sul pool di entropia per produrre output casuali.

3. Una raccolta di sonde entropiche. Questa casualità 'mia' da cose come la rete e l'attività del disco e li aggiunge al pool di entropia.

Il PRNG "disegna" il pool di entropia. L'algoritmo esatto è complicato, ma l'idea di base è che esegua un'operazione di hash crittograficamente protetta sul pool, restituisca parte dell'hash e misuri parte dell'hash nel pool. (Nel codice Linux corrente, in realtà utilizza due operazioni SHA1.)

Le sonde "riempiono" il pool di entropia. L'algoritmo esatto è ancora più complicato (GFSR intrecciato), ma l'idea di base è che il pool viene mescolato e quindi varie informazioni provenienti dalle sonde sono XORed nel pool.

Inoltre, il sistema mantiene una misura di quanto entropia è presente nel pool. Presume che produrre output casuali "esaurisce" il pool e che l'aggiunta di entropia "riempie" il pool. C'è un senso teorico in cui questo è vero, ma in effetti non importa.

Ad esempio, si supponga che un pool di 2048 byte e un utente malintenzionato non sappiano nulla sul contenuto del pool. E poi supponiamo di vedere 8 byte di output dal pool. In teoria, ciò esclude tutti, tranne 1 in 2 ^ 64 possibili condizioni iniziali e lascia solo quelli che produrrebbero quegli esatti 8 byte. Ma non è noto, o addirittura concepibile, che un utente malintenzionato possa utilizzare tali informazioni.

Senza aggiungere entropia aggiuntiva e con 1 GB di output dal PRNG, un utente malintenzionato ha tutte le informazioni di cui ha bisogno per capire le condizioni iniziali del pool e prevedere il prossimo output dal pool. Il problema è che non esiste un metodo noto per farlo oltre a provare tutte le possibili condizioni iniziali 2 ^ (8 * 2048).

Ai fini pratici, ci sono solo due attacchi possibili:

1. Indovina il contenuto aggiunto del pool. Questo fallisce se ci sono più di, ad esempio, 128-bit di dati sconosciuti mescolati nel pool Un utente malintenzionato non può provare 2 ^ 128 o più combinazioni.

2. Indovina il contenuto del pool in un secondo momento. Ma questo richiede di indovinare il intero pool.

In sintesi, a meno che non ci sia un difetto nell'algoritmo, l'output dal pool non rivela informazioni utili sul contenuto del pool. Fintanto che un attaccante non può predire o indovinare tutte le informazioni mescolate nella riserva fino al punto in cui hai tirato fuori dal pool, non può prevedere cosa uscirà dal pool. (Supponendo che non possa guardare all'interno della piscina stessa, ovviamente!)

Panoramica. Non ti biasimo per essere stato confuso. Ci sono molte cattive informazioni là fuori che (ingiustamente) lanciano aspersioni su /dev/urandom .

In effetti, /dev/urandom è sicuro. La versione breve è: usa /dev/urandom e ignora le cose che potresti sentire a riguardo. /dev/urandom è la scelta giusta per quasi tutte le situazioni in cui hai bisogno di numeri casuali forti e di qualità crittografica. /dev/random non è quasi mai la scelta giusta.

Dettagli tecnici. Per le motivazioni alla base delle mie affermazioni, vedi le seguenti domande:

• È un rand di / dev / urandom sicuro per una chiave di accesso?

• Feeding / dev / random entropy pool?

C'è molto scritto lì, e non ho intenzione di ripeterlo.

Il file seme casuale. Per un'approssimazione del primo ordine, puoi ignorare il file seme casuale. Questo è un meccanismo standard presente nella distribuzione Linux per garantire che /dev/urandom sia sicuro. Come sviluppatore di applicazioni, non devi preoccuparti di questo. Succede sotto il cofano. Tutto ciò che devi sapere è che è presente per progettazione, ed è lì per una buona ragione, ed è vantaggioso.

Oh, vuoi la spiegazione completa? OK, eccolo qui. Affinché sia sicuro, /dev/urandom deve ottenere almeno 128 bit di bit casuali veri da qualche parte. Una volta che ha 128 bit o più di vera entropia, da quel momento in poi puoi contare sul suo output per essere sicuro, crittograficamente strong e imprevedibile - indipendentemente da quanto output ne tragga. Quindi l'unica domanda è, da dove vengono quei pezzi di vera casualità?

Il kernel di Linux ha molte fonti da cui raccoglie la casualità vera: ad es., la tempistica delle interruzioni (ad es., pressioni di tasti, I / O) e altre cose di basso livello. Il kernel accumula gradualmente questa casualità in un pool che /dev/urandom utilizza, e una volta che queste fonti hanno prodotto un aggregato o 128 bit circa di vera casualità, sei bravo. Tuttavia, queste fonti producono entropia a un ritmo relativamente basso. Pertanto, immediatamente dopo l'avvio, probabilmente non hanno ancora prodotto abbastanza entropia. Per risolvere questo problema, la distribuzione Linux ha un meccanismo per conservare l'entropia che è stata raccolta attraverso i reboot. quando spegnete il computer, il computer disegna un po 'di casualità dal pool di entropia di /dev/urandom (ricordate che il pool di entropia ora ha probabilmente un'entropia adeguata, quindi dovrebbe essere una buona casualità strong) e lo salva nel file seme casuale . La prossima volta che avvii il computer, al momento dell'avvio il sistema operativo prende entropia dal file seme casuale, assicurando che il pool di /dev/urandom ora abbia almeno 128 bit o più di buona casualità. Pertanto, una volta che il tuo computer accumula abbastanza entropia nel pool, l'output di /dev/urandom sarà buono da quel momento in poi, indipendentemente dal numero di riavvii del computer.