Ist es falsch, / dev / random unter Linux mit / dev / urandom zu verlinken?

Ich teste derzeit gpg --genkeyauf einer Linux-VM. Leider scheint sich diese Software auf /dev/randomdas Sammeln von Entropie zu verlassen und fordert den Benutzer höflich auf, Bildschirme nach Bildschirmen mit kryptografisch zufälliger Eingabe manuell einzugeben, sodass möglicherweise ein Schlüssel generiert wird es, eine andere Datei als Entropiequelle zu verwenden (der Typ in diesem Video stößt auf dasselbe Problem ...).

Es sollte jedoch dem Benutzer freigestellt sein, /dev/urandomstattdessen zu verwenden, da nichts daran auszusetzen ist . Es handelt sich dabei hauptsächlich um eine Reminiszenz an ältere PRNG-Algorithmen, die aus kryptografischer Sicht schwächer waren. Während die NetBSD-Manpage beispielsweise zugesteht, dass die Unterscheidung noch in einem sehr frühen Startstadium nützlich sein kann, beschreibt sie eine Unterscheidung wie "Folklore" und eine "imaginäre Theorie, die sich nur gegen Fantasy-Bedrohungsmodelle verteidigt" . Weder stimmt irgendjemand mit der Menge an Entropie überein, die für diesen Befehl erforderlich ist, noch mit der Tatsache, dass Entropie etwas ist, das tatsächlich verbraucht wird, wie in der GPG-Manpage angegeben ("BITTE, benutze diesen Befehl nur, wenn du weißt, was du tust, da er möglicherweise wertvolle Entropie aus dem System entfernt!" ).

Ich habe von Leutenrngd gelesen , die den Daemon installieren und ihn so konfigurieren, dass er /dev/urandomals Entropiequelle für Feeds verwendet wird /dev/random, aber ich finde diese Vorgehensweise sehr schmutzig.

Ich habe versucht, das Problem auf FreeBSD-Weise zu umgehen, indem ich es entfernte /dev/randomund mit folgendem Link verknüpfte /dev/urandom:

rm /dev/random
ln -s /dev/urandom /dev/random

Ich sehe dies als eine Einstellung, die besagt, dass "Ich vertraue /dev/urandomals Entropiequelle" .

Ich befürchtete, ich könnte auf einen Fehler stoßen, aber dies scheint das erwartete Ergebnis zu liefern, da der Befehl jetzt sofort erfolgreich zurückgegeben wird.

Meine Frage ist: Gibt es irgendwelche bekannten, praktischen und falschen Nebenwirkungen bei der Verknüpfung /dev/randommit /dev/urandomLinux-Systemen, wie sie standardmäßig auf FreeBSD-Systemen durchgeführt werden? Oder könnte man sich vorstellen, dies dauerhaft festzulegen (z. B. in einem Skript am Ende des Startvorgangs), wenn sich Probleme aufgrund der /dev/randomSperrung eines Dienstes wiederholen ?

Siehe Mythen über Urandom , es ist kein Angriff auf / dev / urandom bekannt, der nicht auch ein Angriff auf / dev / random wäre. Das Hauptproblem eines Linux-Systems besteht darin, dass es als mehrere VMs geklont und ausgeführt wird, ohne dass der gespeicherte Entropiepool nach dem Klonen zurückgesetzt wird. Das ist ein Eckfall, der tangential zu dem ist, was Sie wollen.

Ein Unterschied /dev/randombesteht darin, dass die Ausgabe gestoppt wird, nachdem der Entropiepool verwendet wurde. Versuche dies:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/dev/urandomDerselbe Pool wird jedoch wiederverwendet, um die Ausgabe fortzusetzen. wie hier gezeigt:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Wenn Sie versuchen, diese speziellen Geräte zu konfigurieren, ist Ihre Eingabeaufforderung möglicherweise fehlerhaft. Geben Sie einfach etwas resetein, und Ihr Terminal ist wieder normal.)

Verwenden /dev/urandomSie diese Option, wenn Sie nur etwas mit einem konstanten Fluss von "zufälligen" Bits füllen müssen. Verwenden Sie /dev/randomfür Schlüssel, die Sie absolut zufällig sein müssen.

Unter Linux werden /dev/randomzufällige Bits hoher Qualität ausgegeben. Sie stammen aus Quellen, die außerhalb der Maschine nicht vorhersehbar und nicht wiederholbar sind. /dev/urandomVerwendet im Gegensatz dazu dieselben Zufallsdaten wie /dev/random(sofern verfügbar). Wenn keine vorhanden sind, wird ein deterministischer Pseudozufallszahlengenerator verwendet . Für die meisten Zwecke ist es unvorhersehbar genug, aber nicht für sehr anspruchsvolle Anwendungen wie die Kryptografie und viel weniger für die Erstellung langlebiger Schlüssel wie für GPG.