Alternative Entropie-Quellen

Question

Okay, ich schätze, das ist völlig subjektiv und so weiter, aber ich habe über Entropiequellen für Zufallszahlengeneratoren nachgedacht. Die meisten Generatoren werden doch mit der aktuellen Zeit geimpft, oder? Nun, ich war neugierig, welche anderen Quellen verwendet werden könnten, um vollkommen gültige, zufällige (die lose Definition) Zahlen zu erzeugen.

Würde die Verwendung mehrerer Quellen (z. B. Zeit + aktuelle Festplattensuchzeit [wir sind hier phantasievoll]) zusammen eine "zufälligere" Zahl ergeben als eine einzelne Quelle? Wo liegen die logischen Grenzen für die Anzahl der Quellen? Wie viel ist wirklich genug? Wird die Zeit einfach gewählt, weil es bequem ist?

Entschuldigen Sie bitte, wenn dies nicht erlaubt ist, aber ich bin neugierig auf die Theorie hinter den Quellen.

Answer 1

Moderne RNGs werden anhand von Korrelationen in nahe gelegenen Seeds überprüft und führen mehrere hundert Iterationen nach dem Seeding durch. Die leider langweilige, aber wahre Antwort ist also, dass es wirklich keine große Rolle spielt.

Im Allgemeinen muss bei der Verwendung von physikalischen Zufallsprozessen geprüft werden, ob sie einer Gleichverteilung entsprechen und ansonsten nicht verzerrt sind.

Meiner Meinung nach ist es oft besser, einen sehr gut verstandenen Pseudo-Zufallszahlengenerator zu verwenden.

Answer 2

Ich habe ein Verschlüsselungsprogramm verwendet, das die Mausbewegung des Benutzers zur Erzeugung von Zufallszahlen nutzte. Das einzige Problem war, dass das Programm pausieren und den Benutzer auffordern musste, die Maus für ein paar Sekunden nach dem Zufallsprinzip zu bewegen, um richtig zu funktionieren, was nicht immer praktisch sein dürfte.

Answer 3

Ich fand HotBits vor einigen Jahren - die Zahlen werden durch radioaktiven Zerfall erzeugt, wirklich zufällig Zahlen.

Die Anzahl der Zahlen, die man pro Tag herunterladen kann, ist begrenzt, aber es hat mich schon immer amüsiert, diese als sehr, sehr zufällige Seeds für RNG zu verwenden.

Answer 4

Einige TPM-"Chips" (Trusted Platform Module) haben einen Hardware-RNG. Leider verfügt das (Broadcom-)TPM in meinem Dell-Laptop nicht über diese Funktion, aber viele heute verkaufte Computer sind mit einem Hardware-RNG ausgestattet, der wirklich unvorhersehbare quantenmechanische Prozesse verwendet. Intel hat die Variante mit thermischem Rauschen implementiert.

Verwenden Sie auch nicht die aktuelle Zeit allein, um einen RNG für kryptografische Zwecke oder andere Anwendungen, bei denen Unvorhersehbarkeit wichtig ist, zu setzen. Die Verwendung einiger Bits niedriger Ordnung aus der Zeit in Verbindung mit mehreren anderen Quellen ist wahrscheinlich in Ordnung.

A ähnliche Frage kann für Sie nützlich sein.

Answer 5

Tut mir leid, dass ich mich zu spät an dieser Diskussion beteilige (wie alt ist sie jetzt, 3 1/2 Jahre?), aber ich habe ein wiedererwachtes Interesse an der PRN-Erzeugung und alternativen Quellen von Entropie. Der Linux-Kernel-Entwickler Rusty Russell hatte kürzlich eine Diskussion auf seiner Blog zu alternativen Entropiequellen (andere als /dev/urandom ).

Aber ich bin von seinen Entscheidungen nicht sonderlich beeindruckt; die MAC-Adresse einer NIC ändert sich nie (obwohl sie sich von allen anderen unterscheidet), und die PID scheint eine zu kleine mögliche Stichprobengröße zu sein.

Ich habe mich mit einem Mersenne-Twister (auf meinem Linux-Rechner), die mit dem folgenden Algorithmus geseedet wird. Ich bitte um Kommentare/Feedback, falls jemand bereit und interessiert ist:

1. Erstellen eines Array-Puffers mit 64 Bit + 256 Bit * Anzahl der /proc Dateien unten.

2. Platzieren Sie den Wert des Zeitstempelzählers (TSC) in den ersten 64 Bits dieses Puffers.

3. Für jeden der folgenden Punkte /proc Dateien, berechnen Sie die SHA256-Summe:

   • /proc/meminfo
   • /proc/self/maps
   • /proc/self/smaps
   • /proc/interrupts
   • /proc/diskstats

   • /proc/self/stat

     Legen Sie jeden 256-Bit-Hash-Wert in einen eigenen Bereich des in (1) erstellten Arrays.

4. Erstellen eines SHA256-Hashes des gesamten Puffers. HINWEIS: Ich könnte (und sollte wahrscheinlich) eine andere Hash-Funktion verwenden, die völlig unabhängig von den SHA-Funktionen ist - diese Technik wurde als "Schutz" gegen schwache Hash-Funktionen vorgeschlagen.

Jetzt habe ich 256 Bits an HOFFENTLICH zufällige (genügend) Entropiedaten, um meinen Mersenne Twister zu setzen. Ich verwende die oben genannten Daten, um den Anfang des MT-Arrays (624 32-Bit-Ganzzahlen) zu füllen, und initialisiere dann den Rest dieses Arrays mit dem Code des MT-Autors. Außerdem habe ich könnte eine andere Hash-Funktion (z. B. SHA384, SHA512) verwenden, aber ich würde eine andere Größe Array-Puffer (offensichtlich) benötigen.

Der ursprüngliche Mersenne-Twister-Code verlangte einen einzigen 32-Bit-Seed, aber das ist meiner Meinung nach völlig unzureichend. Die Durchführung von "nur" 2^32-1 verschiedenen MTs auf der Suche nach dem Brechen der Krypto ist heutzutage nicht jenseits des Bereichs der praktischen Möglichkeiten.

Ich würde gerne die Meinung anderer dazu lesen. Kritik ist mehr als willkommen. Ich werde meine Verwendung des /proc Dateien wie oben, weil sie sich ständig ändern (insbesondere die /proc/self/* Dateien, und der TSC liefert immer einen anderen Wert (Auflösung im Nanosekundenbereich [oder besser], IIRC). Ich habe Hartnäckige Tests (in der Größenordnung von mehreren hundert Milliarden Bits), und es scheint mit Bravour zu bestehen. Aber das ist wahrscheinlich eher ein Beweis für die Tauglichkeit des Mersenne Twisters als PRNG als dafür, wie ich ihn einsetze.

Natürlich sind das keine völlig unempfindlich gegen Hacker, aber ich kann mir nicht vorstellen, dass all diese (und SHA*) gehackt werden können. und in meinem Leben gebrochen.