Den verfügbaren Zufall mit haveged erhöhen
Obwohl ein Informatiker nichts lieber hat als den Determinismus, sind Zufallszahlen gerade in der modernen Kommunikation ein wichtiger Faktor -- werden sie doch unbedingt für die Kryptographie gebraucht. Ein Computer erzeugt Zufallszahlen entweder mit einer dedizierten Hardware oder über "zufällige" Ereignisse wie Interrupts z.B. weil der Mauszeiger sich bewegt hat. Zufallszahlen werden verbraucht, wenn Kryptographie-Schlüssel erzeugt werden. Inzwischen verbraucht aber auch jeder Prozeßstart 16 Bit Zufall, weil die glibc dies aus /dev/random liest. Wenn zu wenig Zufall vorhanden ist, die Entropie also gering ist, warten diese Prozesse, bis wieder Zufallsbits aus /dev/random zur Verfügung stehen. Es kommt also zu einer schlechteren Performance, Prozesse benötigen länger zum Starten, kryptographische Vorgänge dauern länger. Hinzu kommt, dass ein Server wenige echte Zufallsquellen zur Verfügung stehen hat. Es gibt einfach keinen Benutzer, der die Maus herumschubst. Virtuelle Maschinen haben es da noch schwerer. Der Dämon haveged löst dieses Problem, indem er Zufallszahlen tatsächlich unvorhersagbar zufällig produziert und nicht pseudozufällig wie /dev/urandom. Er bedient sich dabei Gleichlaufschwankungen moderner CPU-Caches. Haveged läuft als Dämon und überwacht die verfügbare Anzahl von Zufalls-Bits. Wird ein eingestellter Schwellwert unterschritten, erzeugt haveged neue Zufalls-Bits. Dies ist sehr effizient und resourcenschonend. Der Zugewinn durch die höhere Entropie überwiegt bei weitem die Last, die haveged zusätzlich auf das System bringt.
Kommentare
4 Antworten zu Den verfügbaren Zufall mit haveged erhöhen
Hi,
eigentlich sollte jede moderne Software /dev/urandom nutzen und somit non-blocking auf den CSPRNG zugreifen.
Warum haveged nicht wirklich sinnvoll ist steht hier recht gut erläutert:
http://security.stackexchange.com/a/34552
Warum man urandom statt random nutzen sollte steht hier:
http://www.2uo.de/myths-about-urandom
Gruß
Sven
Ja, und hier
http://www.golem.de/news/linux-kernel-mehr-zufall-in-linux-3-17-1410-10…
steht, warum /dev/urandom anzuwenden nicht empfohlen wird
VG
Jörn
[…] Entropie mit haveged erhöhen […]
Heul Heul.
Natürlich sollte keiner haveged benutzen, wenn er an einem wichtigen System ist. Aber für einem Raspberry Pi Server, der wegen RealVNC nach jedem Neustart mehrere Minuten lang "hängt", weil nicht genug Entropie vorhanden ist, ist haveged absolut perfekt.