I dati / dev / random sono un cifrario AES psuedo-casuale, e da dove viene l'entropia?


8

La mia attuale comprensione di un pool di entropia è che raccoglie bit di dati veramente casuali a una velocità lenta. Mi piacerebbe sapere come Unix e Linux raccolgono l'entropia e come tale entropia viene utilizzata da / dev / random.

Ho sentito (genericamente) metodi di raccolta dell'entropia come lo stato della cpu della scheda video quando arriva un pacchetto di rete selezionato "casualmente", confrontato con il fattore sibilo nel convertitore digitale-analogico e altri metodi ancora più ottusi.

Credo che l'entropia "pool" sia sfruttato come necessario, e sia usato per seminare un generatore di psuedo casuale ....

Non sto cercando una risposta approfondita, ma sono interessato a sapere se questo è l'approccio generale utilizzato da Unix / Linux? .. e forse alcuni suggerimenti su ciò che sta realmente accadendo sulla faccia di carbone della raccolta di entropia. .. e poi, in che cosa viene immessa l'entropia .. È un codice AES Rijndael?

Le informazioni di base per i miei commenti sopra, provenivano da Security Now di Steve Gibson ! podcast: Episode # 301 Going Random, Part 2 of 2 ... Ha parlato solo genericamente (ma come è il suo stile, con abbastanza dettagli e chiarezza in modo che anche io potessi capirlo. Avere ascoltato i precedenti 300 episodi aiuta :), ... e vorrei sapere se è così che Unix / Linux lo fa ...


Risposte:


14

Linux ha due generatori di numeri casuali disponibili per userspace /dev/randome /dev/urandom.

/dev/randomè una fonte di "vera" casualità, ovvero non è generata da un generatore di numeri pseudo-casuali. L'entropia viene inserita in questo dal driver di input e dal gestore di interrupt, attraverso le funzioni add_input_randomnesse add_interrupt_randomness. I processi di lettura di questo dispositivo si bloccano se l'entropia si esaurisce.

/dev/urandomè un generatore di numeri pseudo-casuale. È alimentato dallo stesso pool di entropia /dev/random, ma quando si esaurisce, passa a un generatore crittograficamente forte.

Le applicazioni dello spazio utenti possono essere inserite nel pool di entropia scrivendo a /dev/{,u}random.

Leggi la pagina del manuale casuale (4) e il file drivers/char/random.cnella struttura dei sorgenti del kernel. È ben commentato e la maggior parte di ciò che chiedi è spiegato lì.


Di /dev/randomdefault FreeBSD è un generatore di numeri pseudo-casuale che usa l'algoritmo Yarrow (ma può puntare a un RNG hardware se è collegato). Il generatore di software prende l'entropia dalle connessioni Ethernet e seriali e dagli interrupt di processo (modificabili sysctl kern.random). Si ritiene che l'algoritmo di Yarrow sia sicuro fintanto che lo stato interno è sconosciuto, pertanto /dev/randomdovrebbe sempre generare dati di alta qualità senza blocco. Vedi casuale (4) .

Su NetBSD, /dev/randomfornisce dati casuali basati solo sull'entropia raccolta (da dischi, rete, dispositivi di input e / o unità nastro; regolabile mediante rndctl ), mentre /dev/urandomricade su un PRNG quando il pool di entropia è vuoto, simile a Linux. Vedi random (4) , rndctl (8) , rnd (9) .

OpenBSD ha quattro generatori: /dev/randomè un generatore hardware, /dev/srandomè un generatore di dati casuali sicuro (utilizzando MD5 sul pool di entropia: "interruzioni del disco e dei dispositivi di rete e simili"), /dev/urandomè simile ma ricade in un PRNG quando il pool di entropia è vuoto. Il quarto /dev/arandomè anche un PRNG ma utilizza RC4 . Vedi random (4) , arc4random (3) .

Mac OS X utilizza anche l'algoritmo Yarrow per /dev/random, ma ha identicamente funzionante /dev/urandomper la compatibilità. "L'entropia aggiuntiva viene fornita regolarmente al generatore dal demone SecurityServer da misurazioni di jitter casuali del kernel." Vedi casuale (4) .


Grazie. Una buona visione d'insieme, e dalla fonte, vedo che siamo al sicuro nelle mani di un Twisted Generalized Feedback Shift Register (cose spaventose :) ... Insieme a ottusi input "casuali" nel pool, sembra che un hash SHA sia generato "attraverso il pool, 16 parole (512 bit) alla volta" e mischiato nuovamente nel pool, e poi alcune altre girazioni vengono eseguite sul pool ... Steve Gibson commenta nel suo podcast che: SHA-256 utilizza / è il più forte hash dello stato dell'arte che abbiamo. ... Non ho scoperto cosa genera output / dev / urandom, ma il processo di lead-up è sicuramente significativo
Peter.O

+1, buona risposta; Una volta ho provato a generare dati casuali sui personaggi cat /dev/randome mi sono sempre chiesto perché il mio stream si è fermato dopo così tanti personaggi
Mike Pennington,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.