Gibt es eine Möglichkeit, /dev/randommit ausreichend Entropie zu füttern? Die Daten müssen nicht wirklich zufällig sein, d. h. ich kann die Tageszeit mit PID anhängen und 27 hinzufügen, das spielt keine Rolle, ich möchte es nur schneller laufen lassen.
Ich habe versucht, den Ball mit ins Rollen zu bringen dd if=/dev/zero of=/dev/null. Ich möchte wissen, ob es eine Möglichkeit gibt, add_keystroke_randomnessin /linux/random.hkünstlich zu füttern /dev/random, damit ich diese unvorhersehbaren blockierenden Anrufe nicht bekomme. D. h. ich bin bereit, etwas Zufälligkeit zugunsten der Geschwindigkeit zu opfern.
PS - bitte schlagen Sie nicht vor,/dev/urandom
Antwort1
Es gibt verschiedene Lösungen zur Erzeugung von Entropie. Beispielsweise haveged(womit ich selbst sehr zufrieden bin), timer_entropyd, audio-entropyd, usw. usw. erzeugen sie normalerweise genug Entropie für die meisten Anwendungen, die verwenden /dev/random. Wenn Sie aufs Ganze gehen wollen, gibt es auch Hardware-Zufallsgeneratoren, die als USB-Sticks erhältlich sind. Diese erzeugen jedoch möglicherweise weniger Entropie, als Sie denken ...
Dennoch /dev/urandomist es immer eine gute Wahl, wenn Daten ohne Verzögerung verfügbar sein müssen.
Für große Datenmengen (wie etwa das Überschreiben von Festplatten) ist keines der Zufallsgeräte hinsichtlich der Geschwindigkeit geeignet, ungeachtet der verfügbaren Entropie. Eine PRNG-basierte Lösung wie diese shrederledigt diese Aufgabe besser/schneller.
Antwort2
(Meine Antwort bezieht sich auf Linux. Die allgemeinen Grundsätze gelten auch für andere Unix-Varianten, jedoch nicht der Unterschied zwischen random/ und urandomLinux.)
Dies geschieht bereits im Kernel.
Es schadet nie, zusätzliche Entropie einzubringen. Wenn Sie einen Haufen pseudozufälliger Bytes herumliegen haben, schreiben Sie sie einfach in /dev/random, und sie werden in den Entropiepool gemischt.
Havegeist ein beliebtes Programm zum Sammeln zusätzlicher Entropie.
dd if=/dev/zero of=/dev/nullverursacht keine Hardware-E/A und fügt daher keine Entropie hinzu. Tastenanschläge enthalten eine winzige Menge an Entropie.
/dev/randomBeachten Sie, dass Sie es falsch machen, wenn Sie unter Linux lesen . Die Linux-DesignerHabe es falsch verstanden: Sie erklärten, dass Entropie etwas ist, das schnell verbraucht wird, wasist nicht der FallDie Lösung für „ /dev/randomBlöcke“ ist nicht „mehr Entropie einbringen“, sondern „stattdessen das entsprechende Gerät verwenden“. Ob Sie es hören wollen oder nicht,Sie sollten lesen von/dev/urandom.
Antwort3
Je nach Kernelversion implementiert Linux add_disk_randomness(), add_input_randomness(), und add_interrupt_randomness()als Entropiequellen. Diese entsprechen Festplatten-E/A-Ereignissen, Tastatur- und Mausereignissen und Interrupt-Ereignissen (IRQ). Die genaue Implementierung finden Sie in random.c. Diese Quellen werden intern aufbereitet, gemischt und gespeichert und verwendet, um blockierende /dev/randomund nicht blockierende /dev/urandomTreiber zu speisen. In diesem Fall bedeutet nicht blockierend, dass ein Aufruf /dev/urandomvon immer eine Ausgabe erzeugt, auch wenn der Entropiepool keine Entropie enthält. So unwahrscheinlich /dev/urandomdie Verwendung auch sein mag, sie kann zu einer Seeding-Rate mit geringer Entropie und einem vorhersehbaren deterministischen RNG führen. Dies kann wiederum zu beschädigter Verschlüsselung führen, wobei RSA besonders anfällig für Bedingungen mit geringer Entropie ist. Sie sollten also nicht /dev/urandomfür die Kryptografie verwenden. Die Entropie beim Booten /dev/urandomist jedoch auf Headless-Systemen dauerhaft problematisch und würde zusätzliche Entropiequellen erfordern, um richtig zu funktionieren.
Die einfachste Lösung für unzureichende Boot-Entropie ist die Aktivierung von RdRand(oder RdSeed) über hw_rand, aber dazu muss man der Black-Box-Implementierung von Intel (und jetzt auch AMD) vertrauen. Wenn Sie QorlQ verwenden, gibt es eine entsprechende SEC-Funktionalität.
Alternativ gibt es Software-Zufallszahlengeneratoren, die Sie implementieren können. Meine Empfehlung istCPU-Zeitjittervon Stephan Müller, da es ein gut dokumentiertes Design ist und sich leicht in bestehende Systeme integrieren lässt. Beachten Sie, dass es ohne Optimierungen kompiliert werden muss, um maximale Entropieergebnisse zu erzielen.