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.

Dieser Beitrag wurde unter Blog, Howtos, Security veröffentlicht. Setze ein Lesezeichen auf den Permalink.

3 Kommentare zu Den verfügbaren Zufall mit haveged erhöhen

  1. Sven sagt:

    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

  2. Jörn sagt:

    Ja, und hier
    http://www.golem.de/news/linux-kernel-mehr-zufall-in-linux-3-17-1410-109637-2.html
    steht, warum /dev/urandom anzuwenden nicht empfohlen wird

    VG
    Jörn

  3. Pingback: Linkdump 2014-0 (1) | Natenoms Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.