Ich habe einige Arbeiten angefangen, von denen einige zufällige Qualitätsbytes, z. B. 32 für einen initialisierenden Vektor für bestimmte kryptografische Anwendungen, benötigt werden. Mein Problem ist, dass dies mehrmals gleichzeitig aufgerufen werden kann und ich kann mir die Block /dev/random issues nicht leisten, um auf eine weitere Entropiesammlung zu warten.
Ich könnte es verwenden, um andere Algorithmen zu säen, zum Beispiel was /dev/urandom tun kann - aber ich traue nicht, was ich nicht verstehe, ich habe keine leicht verfügbare Ressource auf seiner Methode noch weiß ich, ob es das bleibt Das selbe zwischen vielen Kernel-Versionen, bevorzuge ich eine wohldefinierte Methode irgendeiner Art.
Sind Ihnen irgendwelche Methoden bekannt, die Sie über Standard-PRNGs denken können, die für die (gleichzeitige) Schlüsselgenerierung und ähnliches gleichermaßen geeignet wären?
Würden bestimmte Chiffren wie RC4 mit einem großen Seed ausreichen, um eine zufällige Ausgabe zu erzeugen? (Ich habe eine Implementierung von / dev / frandom gesehen, die dies verwendet, bin mir aber nicht ganz sicher.)
Wenn es irgendetwas bedeutet, bin ich auf einem kopflosen Debian-Server, Grund für das Fehlen der Entropie-Sammlung.
Die Antwort ist einfach: Verwenden Sie /dev/urandom , nicht /dev/random . /dev/urandom ist kryptografisch sicher und blockiert nicht. Die "Überlegenheit" von /dev/random über /dev/urandom existiert nur in einer speziellen theoretischen Einstellung, die keinen Sinn ergibt, wenn die zufälligen Bytes mit fast jedem "normalen" kryptografischen Algorithmus, wie Verschlüsselung oder Signaturen, verwendet werden sollen.
Siehe dies für weitere Details.
(Vertrau mir, ich bin ein Kryptograf.)
Erwägen Sie die Verwendung eines Hardware-Zufallszahlengenerators. Zum Beispiel der Entropie-Schlüssel oder Whirlygig . Wenn Sie stattdessen /dev/urandom verwenden, vermeiden Sie Blockierungen, können aber (abhängig von Ihrem Paranoia-Grad) die Sicherheit verschlechtern (Sie geben mehr zufällige Bits aus als Sie Entropie eingegeben haben, also ist die Ausgabe theoretisch vorhersehbar - dies ist kein Problem für Sie verwende es nur für IVs jedoch)
Sie können versuchen, die Ausgabe (oder einen Hash davon) von /bin/ps -A v oder /bin/ps -A s zu verwenden. Ich bin mir jedoch nicht sicher, ob dieser Befehl in allen oder den meisten Linux-Distributionen verfügbar ist.
Wenn Sie sich für /dev/urandom entscheiden, sollten Sie die Entropie der zufälligen Bytes berechnen, die von dieser Quelle erzeugt werden, vorzugsweise die Min-Entropie .
Auf einer modernen CPU mit AES-Hardwarebeschleunigung können Sie einfach mehr als 1 GiB / s an zufälligen Daten erreichen, indem Sie eine Folge von Nullen mit einem zufälligen Passwort (aus /dev/urandom ) verschlüsseln gezeigt von eine andere Antwort auf Serverfault . Beachten Sie, dass das zufällige Passwort als Pipe übergeben wird, so dass es nicht in der Prozessliste angezeigt wird.
Dieser Ansatz ist auf meinem Rechner ungefähr 100 mal schneller als /dev/urandom :
Wenn Sie dies in ein Shell-Skript einfügen, können Sie es einfach in andere Prozesse leiten:
%Vor%Tags und Links random linux cryptography prng