Ist / dev / random data eine pseudozufällige AES-Chiffre und woher kommt die Entropie?

Mein derzeitiges Verständnis eines Entropiepools ist, dass er wirklich zufällige Datenbits mit einer langsamen Geschwindigkeit sammelt . Ich würde gerne wissen, wie Unix & Linux Entropie sammeln und wie diese Entropie von / dev / random verwendet wird.

Ich habe (allgemein) von Entropie-Erfassungsmethoden wie dem Status der Grafikkarten-CPU gehört, wenn ein "zufällig" ausgewähltes Netzwerkpaket eintrifft, das mit dem Rauschfaktor im Digital-Analog-Wandler verglichen wird, und anderen noch stumpferen Methoden.

Ich glaube, dass der Entropie- "Pool" nach Bedarf abgegriffen wird und verwendet wird, um einen Pseudo-Zufallsgenerator zu erzeugen ....

Ich bin nicht auf der Suche nach einer eingehenden Antwort, aber ich bin interessiert zu wissen, ob dies der allgemeine Ansatz von Unix / Linux ist? .. und vielleicht einige Hinweise darauf, was tatsächlich auf der Entropy-Collection-Kohlefläche vor sich geht. .. und in was wird dann die Entropie eingespeist .. Ist es eine AES Rijndael Chiffre?

Die Hintergrundinformationen für meine obigen Kommentare stammen von Steve Gibsons Security Now! Podcast: Episode # 301 Going Random, Teil 2 von 2 ... Er sprach nur generisch (aber wie sein Stil, mit genügend Details und Klarheit, so dass selbst ich ihn verstehen konnte. Das Anhören der vorhergehenden 300 Folgen hilft :), ... und ich würde gerne wissen, ob Unix / Linux das so macht ...

Linux hat zwei Zufallszahlen - Generatoren zur Verfügung User - Space, /dev/randomund /dev/urandom.

/dev/randomist eine Quelle "wahrer" Zufälligkeit - dh sie wird nicht von einem Pseudozufallszahlengenerator erzeugt. Die Entropie wird vom Eingabetreiber und vom Interrupt-Handler über die Funktionen add_input_randomnessund eingespeist add_interrupt_randomness. Prozesse, die dieses Gerät lesen, werden blockiert, wenn die Entropie aufgebraucht ist.

/dev/urandomist ein Pseudozufallszahlengenerator. Es wird von demselben Entropiepool gespeist wie /dev/random, aber wenn dieser aufgebraucht ist, schaltet es auf einen kryptografisch starken Generator um.

Userspace-Anwendungen können durch Schreiben an in den Entropiepool eingespeist werden /dev/{,u}random.

Lesen Sie die zufällige (4) Handbuchseite und die Datei drivers/char/random.cim Kernel-Quellbaum. Es ist gut kommentiert und das meiste, was Sie fragen, wird dort erklärt.

FreeBSDs sind /dev/randomstandardmäßig ein Pseudozufallszahlengenerator, der den Yarrow-Algorithmus verwendet (kann jedoch auf ein Hardware-RNG verweisen, wenn eines angeschlossen ist). Der Softwaregenerator nimmt Entropie von Ethernet- und seriellen Verbindungen und Hardware-Interrupts (austauschbar durch sysctl kern.random). Es wird angenommen, dass der Yarrow-Algorithmus sicher ist, solange der interne Status unbekannt ist. Daher /dev/randomsollte er immer qualitativ hochwertige Daten ausgeben, ohne sie zu blockieren. Siehe zufällig (4) .

Stellt unter NetBSD /dev/randomzufällige Daten bereit, die nur auf der gesammelten Entropie basieren (von Festplatten, Netzwerk, Eingabegeräten und / oder Bandlaufwerken; mit rndctl einstellbar ), während /dev/urandombei leerem Entropiepool auf PRNG zurückgegriffen wird, ähnlich wie bei Linux. Siehe zufällig (4) , rndctl (8) , rnd (9) .

OpenBSD hat vier Generatoren: /dev/randomist ein Hardware-Generator, /dev/srandomist ein sicherer Zufallsdatengenerator (unter Verwendung von MD5 im Entropiepool: "Interrupts von Festplatten und Netzwerkgeräten und dergleichen"), /dev/urandomist ähnlich, greift jedoch auf einen PRNG zurück, wenn der Entropiepool leer ist. Das vierte /dev/arandomist ebenfalls ein PRNG, verwendet jedoch RC4 . Siehe zufällig (4) , arc4 zufällig (3) .

Mac OS X verwendet ebenfalls den Yarrow-Algorithmus für /dev/random, arbeitet jedoch /dev/urandomaus Kompatibilitätsgründen identisch . "Der SecurityServer-Daemon speist dem Generator regelmäßig zusätzliche Entropie aus zufälligen Jitter-Messungen des Kernels." Siehe zufällig (4) .