Sie können an /dev/random schreiben weil es Teil des Weges ist, /dev/random zusätzliche zufällige Bytes bereitzustellen , aber es ist nicht ausreichend, Sie müssen dem System auch mit ioctl() mitteilen, dass zusätzliche Entropie vorhanden ist Anruf.
Ich brauchte die gleiche Funktionalität zum Testen meines Smartcard-Setup-Programms, da ich nicht warten wollte, bis meine Maus/Tastatur genug für die mehreren Aufrufe von gpg erzeugt hat die für jeden Testlauf gemacht wurden. Ich habe das folgende Python-Programm parallel zu meinen Tests ausgeführt. Das sollte es natürlich nicht überhaupt für echte gpg verwendet werden Schlüsselgenerierung, da die zufällige Zeichenfolge überhaupt nicht zufällig ist (vom System generierte zufällige Informationen werden immer noch verschachtelt). Wenn Sie eine externe Quelle haben, um die Zeichenfolge für random festzulegen , dann 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.)
Typischerweise wird es von Kernel-Entwicklern entworfen und in man 4 random dokumentiert :
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.