Sie beobachten eine Kombination des eigentümlichen Verhaltens von dd mit dem eigentümlichen Verhalten von /dev/random von Linux . Beides ist übrigens selten das richtige Werkzeug für den Job.
/dev/random von Linux gibt Daten sparsam zurück. Es basiert auf der Annahme, dass die Entropie im Pseudozufallszahlengenerator sehr schnell gelöscht wird. Da das Sammeln neuer Entropie langsam ist, /dev/random gibt normalerweise nur wenige Bytes auf einmal ab.
dd ist ein altes, verschrobenes Programm, das ursprünglich für den Betrieb auf Bandgeräten gedacht war. Wenn Sie ihm sagen, dass er einen Block von 1 KB lesen soll, versucht er, einen Block zu lesen. Wenn der Lesevorgang weniger als 1024 Bytes zurückgibt, ist das alles, was Sie bekommen. Also dd if=/dev/random bs=1K count=2 macht zwei read(2) Anrufe. Da es von /dev/random liest , die beiden read Aufrufe geben normalerweise nur wenige Bytes zurück, je nach verfügbarer Entropie in unterschiedlicher Anzahl. Siehe auch Wann eignet sich dd zum Kopieren von Daten? (oder wenn read() und write() partiell sind)
Wenn Sie keinen OS-Installer oder -Kloner entwerfen, sollten Sie niemals /dev/random verwenden unter Linux immer /dev/urandom . Die urandom Manpage ist etwas irreführend; /dev/urandom ist nämlich für die Kryptografie geeignet, sogar um langlebige Schlüssel zu erzeugen. Einzige Einschränkung bei /dev/urandom ist, dass es mit ausreichend Entropie versorgt werden muss; Linux-Distributionen speichern normalerweise die Entropie zwischen Neustarts, sodass Sie möglicherweise nur bei einer Neuinstallation nicht genügend Entropie haben. Entropie nutzt sich praktisch nicht ab. Weitere Informationen finden Sie unter Ist ein Rand von /dev/urandom sicher für einen Anmeldeschlüssel? und Feeding /dev/random entropy pool?.
Die meisten Verwendungen von dd lassen sich besser mit Tools wie head ausdrücken oder tail . Wenn Sie 2 KB zufällige Bytes möchten, führen Sie
head -c 2k </dev/urandom >rand
Mit älteren Linux-Kerneln könnten Sie mit
davonkommendd if=/dev/urandom of=rand bs=1k count=2
weil /dev/urandom gerne so viele Bytes wie angefordert zurückgegeben. Dies gilt jedoch seit Kernel 3.16 nicht mehr, es ist jetzt auf 32 MB begrenzt.
Im Allgemeinen, wenn Sie dd verwenden müssen Um eine feste Anzahl von Bytes zu extrahieren und deren Eingabe nicht von einer regulären Datei oder einem Blockgerät kommt, müssen Sie Byte für Byte lesen:dd bs=1 count=2048 .
Ab man 4 random auf einer RHEL 5-Box:
Beim Lesen gibt das Gerät /dev/random nur zufällige Bytes innerhalb der geschätzten Anzahl von Rauschbits im Entropiepool zurück.
Ich bekomme Dateien mit einer Größe von 213 Bytes auf dieser Maschine. Zurück zu zufälligem Mann 4:
Beim Lesen gibt das /dev/urandom-Gerät so viele Bytes wie angefordert zurück.
Ich bekomme 2048 Bytes von jedem Aufruf von dd if=/dev/urandom of=rand bs=1K count=2
Ich schließe daraus, dass der Unterschied darauf zurückzuführen ist, wie viel Entropie Ihre Maschine zwischen den Aufrufen von dd if=/dev/random ... erzeugt
Warum wird dd Daten löschen? ... Gilles hat diese fesselnde Frage zu dd gestellt :
Wann eignet sich dd zum Kopieren von Daten? (oder wenn read() und write() partiell sind)
Hier ist ein Auszug aus dieser Frage:
*...es ist nicht schwer, dd die Schuld zu geben; Versuchen Sie zum Beispiel diesen Code:**
yes | dd of=out bs=1024k count=10
und überprüfen Sie die Größe der Ausgabedatei (sie liegt wahrscheinlich weit unter 10 MB).
Abgesehen von meinem Kommentar (am Ende Ihrer Frage) ist so etwas interessant anzusehen ... Es fängt Ihre Bytes in der Datei $trnd ab . Ich habe halb willkürlich bs=8
Bewegen Sie Ihre Maus und beobachten Sie, wie sie schneller wird.
Mit meinem Computer im Leerlauf (AFK und keine Netzwerkaktivität) und nachdem der Entropiepool erschöpft war, dauerte es 2 Stunden 12 Minuten um nur 1192 zu sammeln Bytes, an welcher Stelle ich es abgebrochen habe.
Wenn ich dann die Maus kontinuierlich bewegte, dauerte es relativ viel kürzere 1 Minute 15 Sekunden um die gleiche Anzahl von Bytes zu sammeln.
Dies zeigt ziemlich deutlich, dass das Sammeln von Entropie nicht auf der CPU-Geschwindigkeit basiert, sondern auf zufälligen Ereignissen basiert und dass mein Ubuntu-System die Maus als eine seiner wesentlichen verwendet Zufallsfaktoren.
get=2048
trnd=/tmp/$USER.rnd; >"$trnd"
while (( $(wc -c <"$trnd") < $get )) ;do
dd if=/dev/random bs=8 count=1 2>/dev/null >>"$trnd"
echo -n "itt: $((i+=1)) ct: "; wc -c <"$trnd"
done
truncate -s $get "$trnd"
echo -e "\nfinal count: "; wc -c <"$trnd"