Lösung 1:
Ihr System sammelt einige "echte" Zufallszahlen, indem es verschiedene Ereignisse im Auge behält:Netzwerkaktivität, Hardware-Zufallszahlengenerator (falls verfügbar; VIA-Prozessoren haben beispielsweise normalerweise einen "echten" Zufallszahlengenerator) und so weiter. Wenn diese dem Kernel-Entropie-Pool zugeführt werden, der von /dev/random verwendet wird. Anwendungen, die extreme Sicherheit benötigen, neigen dazu, /dev/random als ihre Entropiequelle zu verwenden, oder mit anderen Worten, die Zufälligkeitsquelle.
Wenn /dev/random keine verfügbare Entropie mehr hat, kann es nicht mehr Zufälligkeit liefern und die Anwendung wartet auf die Zufälligkeit, bis mehr zufälliges Zeug verfügbar ist. Das Beispiel, das ich während meiner Karriere gesehen habe, ist, dass der IMAP-Daemon von Cyrus /dev/random für die Zufälligkeit verwenden wollte und seine POP-Sitzungen die zufälligen Zeichenfolgen in APOP-Verbindungen aus /dev/random generieren wollten. In einer geschäftigen Umgebung gab es mehr Anmeldeversuche als Datenverkehr zum Einspeisen von /dev/random -> alles ist ins Stocken geraten. In diesem Fall installierte ich rng-tools und aktivierte den darin enthaltenen rngd – der semi-zufällige Zahlen von /dev/urandom nach /dev/random schaufelte, falls /dev/random keine „echte“ Entropie mehr hatte.
Lösung 2:
Wenn Sie einen einfacheren Überblick über das zugrunde liegende Problem wünschen:Einige Anwendungen (z. B. Verschlüsselung) benötigen Zufallszahlen. Sie können Zufallszahlen mit einem Algorithmus generieren – aber obwohl diese in gewisser Hinsicht zufällig erscheinen, sind sie in anderer Hinsicht vollständig vorhersehbar. Wenn ich Ihnen zum Beispiel die Ziffern 58209749445923078164062862089986280348253421170679 gebe, sehen sie ziemlich zufällig aus. Aber wenn Sie erkennen, dass es sich tatsächlich um Ziffern von PI handelt, wissen Sie, dass die nächste 8 sein wird.
Für einige Anwendungen ist dies in Ordnung, aber für andere Anwendungen (insbesondere sicherheitsrelevante) möchten die Leute echte unvorhersehbare Zufälligkeit - die nicht von einem Algorithmus (dh einem Programm) erzeugt werden kann, da dies per Definition vorhersehbar ist. Dies ist insofern ein Problem, als Ihr Computer im Wesentlichen ist ein Programm, wie kann es also echte Zufallszahlen erhalten? Die Antwort besteht darin, wirklich zufällige Ereignisse von der Außenwelt zu messen – zum Beispiel Lücken zwischen Ihren Tastendrücken und diese zu verwenden, um echte Zufälligkeit in den ansonsten vorhersehbaren Zufallszahlengenerator einzufügen. Den 'Entropiepool' könnte man sich als Speicher dieser Zufälligkeit vorstellen, der durch die Tastenanschläge (oder was auch immer verwendet wird) aufgebaut und durch die Generierung von Zufallszahlen geleert wird.
Lösung 3:
Entropie ist ein Fachbegriff für „Zufälligkeit“. Computer erzeugen nicht wirklich Entropie, sondern sammeln sie, indem sie Dinge wie die Variationen der Rotationsgeschwindigkeiten von Festplatten betrachten (ein physikalisches Phänomen, das aufgrund von Reibung usw. sehr schwer vorherzusagen ist). Wenn ein Computer pseudozufällige Daten erzeugen möchte, erzeugt er a mathematische Formel mit echter Entropie, die es durch Messen von Mausklicks, Festplatten-Spin-Variationen usw. gefunden hat. Grob gesagt entropy_avail ist das Maß der aktuell verfügbaren Bits, die von /dev/random gelesen werden können
Der Computer braucht Zeit, um Entropie aus seiner Umgebung zu lesen, es sei denn, er hat coole Hardware wie eine verrauschte Diode oder so etwas.
Wenn Sie 4096 Bit Entropie zur Verfügung haben und Sie /dev/random kategorisieren Sie können davon ausgehen, dass Sie 512 Bytes Entropie (4096 Bits) lesen können, bevor die Datei blockiert, während sie auf mehr Entropie wartet.
Wenn Sie beispielsweise „cat /dev/random ” Ihre Entropie wird auf Null schrumpfen. Zuerst erhalten Sie 512 Bytes zufälligen Müll, aber es hört auf und nach und nach werden Sie mehr zufällige Daten durchsickern sehen.
So sollten Menschen /dev/random nicht bedienen obwohl. Normalerweise lesen Entwickler eine kleine Datenmenge, z. B. 128 Bit, und verwenden diese, um eine Art PRNG-Algorithmus zu erstellen. Es ist höflich, keine weitere Entropie von /dev/random abzulesen als Sie brauchen, da der Aufbau so lange dauert und als wertvoll angesehen wird. Also, wenn Sie es durch unvorsichtiges cat entleeren Wenn Sie die Datei wie oben verwenden, veranlassen Sie andere Anwendungen, von /dev/random zu lesen blockieren. Auf einem System bei der Arbeit stellten wir fest, dass viele Kryptofunktionen ins Stocken gerieten. Wir entdeckten, dass ein Cron-Job ein Python-Skript aufrief, das ständig ramdom.random() initialisierte bei jedem Lauf, der alle paar Sekunden lief. Um dies zu beheben, haben wir das Python-Skript so umgeschrieben, dass es als Daemon lief, der nur einmal initialisiert wurde, und der Cron-Job Daten über XMLRPC lesen würde, sodass er nicht weiter von /dev/random lesen würde beim Start.
Lösung 4:
Die schreibgeschützte Datei entropy_avail gibt die verfügbare Entropie an. Normalerweise sind dies 4096 (Bits), ein voller Entropiepool.
Weitere Informationen finden Sie unter:http://linux.die.net/man/4/random