Warum beschleunigt das Schreiben in / dev / random das parallele Lesen von / dev / random nicht?

Das Lesen von /dev/randomerzeugt normalerweise 100-500 Bytes und Blöcke und wartet darauf, dass eine Entropie gesammelt wird.

Warum /dev/randombeschleunigt das Schreiben von Informationen durch andere Prozesse das Lesen nicht? Sollte es nicht die erforderliche Entropie liefern?

Es kann nützlich sein, um eine Blockierung gpgoder ähnliche Software aufzuheben, ohne sie neu zu starten und alles erneut einzugeben , um nicht-super-streng geheime Schlüssel zu generieren usw.

Sie können schreiben, /dev/randomda dies Teil der Möglichkeit ist, zusätzliche Zufallsbytes bereitzustellen. Dies /dev/randomist jedoch nicht ausreichend. Sie müssen das System auch über einen ioctl()Aufruf darüber informieren, dass zusätzliche Entropie vorhanden ist .

Ich brauchte die gleiche Funktionalität zum Testen meines Smartcard-Setup-Programms , da ich nicht warten wollte, bis meine Maus / Tastatur genug generiert hatte, um die verschiedenen Aufrufe gpgfür jeden Testlauf auszuführen. Ich habe das folgende Python-Programm parallel zu meinen Tests ausgeführt. Es sollte natürlich überhaupt nicht für die gpgGenerierung von echten Schlüsseln verwendet werden, da die zufällige Zeichenfolge überhaupt nicht zufällig ist (vom System generierte zufällige Informationen werden weiterhin verschachtelt). Wenn Sie eine externe Quelle zum Festlegen der Zeichenfolge haben random, sollten Sie in der Lage sein, eine hohe Entropie zu haben. Sie können die Entropie überprüfen mit:

cat /proc/sys/kernel/random/entropy_avail

Das Programm:

#!/usr/bin/env python
# For testing purposes only 
# DO NOT USE THIS, THIS DOES NOT PROVIDE ENTROPY TO /dev/random, JUST BYTES

import fcntl
import time
import struct

RNDADDENTROPY=0x40085203

while True:
    random = "3420348024823049823-984230942049832423l4j2l42j"
    t = struct.pack("ii32s", 8, 32, random)
    with open("/dev/random", mode='wb') as fp:
        # as fp has a method fileno(), you can pass it to ioctl
        res = fcntl.ioctl(fp, RNDADDENTROPY, t)
    time.sleep(0.001)

(Vergessen Sie nicht, das Programm zu beenden, nachdem Sie fertig sind.)

Normalerweise wird es von Kernel-Entwicklern entwickelt und dokumentiert in man 4 random:

Writing to /dev/random or /dev/urandom will update the entropy pool
with the data written, but this will not result in a higher entropy
count.  This means that it will impact the contents read from both
files, but it will not make reads from /dev/random faster.

Anthony hat bereits erklärt, dass Schreiben auf /dev/randomdie Entropiezahl nicht erhöht, und gezeigt, wie das RNDADDENTROPY ioctl (siehe random (4) ) verwendet werden kann, um Entropie anzurechnen . Es ist offensichtlich nicht wirklich sicher, daher gibt es hier eine Alternative, wenn ein Hardware-Zufallszahlengenerator verfügbar ist.

Die folgenden Implementierungen nehmen 512 Bytes (4096 Bits) Zufälligkeit /dev/hwrngund leiten sie an den Entropiepool weiter (Gutschrift von 4 Bits Entropie pro Byte, dies ist eine willkürliche Wahl von mir). Danach ruft es das auf select (2) auf, um zu blockieren, wenn der Entropiepool voll ist (dokumentiert in der Manpage random (4) ).

Eine Python-Version:

import fcntl, select, struct
with open('/dev/hwrng', 'rb') as hw, open('/dev/random') as rnd:
    while True:
        d = hw.read(512)
        fcntl.ioctl(rnd, 0x40085203, struct.pack('ii', 4 * len(d), len(d)) + d)
        select.select([], [rnd], [])

Da auf Arch Linux nicht Python installiert war, gibt es auch hier eine Perl-Version:

open my $hw, "</dev/hwrng" and open my $rnd, "</dev/random" or die;
for (;;) {
    my $l = read $hw, my $d, 512;
    ioctl $rnd, 0x40085203, pack("ii", 4 * $l, $l) . $d or die;
    vec(my $w, fileno $rnd, 1) = 1;
    select undef, $w, undef, undef
}

Dies ist wahrscheinlich das, was das rngd-Programm (Teil von rng-tools ) macht (nicht verifiziert), außer dass es Tools (Python oder Perl) verwendet, die bereits allgemein verfügbar sind.