Ich teste derzeit gpg --genkeyauf einer Linux-VM. Leider scheint diese Software darauf angewiesen zu sein, /dev/randomEntropie zu sammeln, und fordert den Benutzer höflich auf, Bildschirm für Bildschirm kryptografisch zufällige Eingaben manuell einzugeben, sodass sie möglicherweise irgendwann einen Schlüssel generiert, und ich habe keinen Befehlszeilenparameter gefunden, um ihr zu sagen, dass sie eine andere Datei als Entropiequelle verwenden soll (der Typauf diesem Videostößt auf genau dasselbe Problem ...).
Der Benutzer sollte jedoch die freie Wahl haben, /dev/urandomstattdessen zu verwenden, daes ist nichts falsch daran. Es ist hauptsächlich eine Reminiszenz an ältere PRNG-Algorithmen, die aus kryptographischer Sicht schwächer waren. Während beispielsweiseNetBSD-Manpageräumt ein, dass die Unterscheidung in einem sehr frühen Boot-Stadium noch nützlich sein kann, und beschreibt diese Unterscheidung als"Folklore"und ein„imaginäre Theorie, die nur gegen Fantasie-Bedrohungsmodelle schützt“. Niemand stimmt mit beidem übereindie Menge an Entropie, die dieser Befehl benötigtnoch die Tatsache, dass Entropie etwas ist, das tatsächlich verbraucht wird, wie inGPG-Manpage(„Bitte verwenden Sie diesen Befehl nicht, wenn Sie nicht wissen, was Sie tun. Dadurch kann dem System wertvolle Entropie entzogen werden!“).
Ich habe gelesen überPersonen, die den rngdDaemon installierenund konfigurieren Sie es so, dass es /dev/urandomals Entropiequelle zur Zufuhr verwendet wird /dev/random, aber ich halte eine solche Vorgehensweise für äußerst unsauber.
Ich habe versucht, das Problem auf die FreeBSD-Art zu umgehen, indem ich /dev/randomes entfernt und /dev/urandomstattdessen mit Folgendem verknüpft habe:
rm /dev/random
ln -s /dev/urandom /dev/random
Ich sehe das als eine Einstellung, die„Ich vertraue /dev/urandomals Entropiequelle“.
Ich hatte befürchtet, dass ich auf irgendeinen Fehler stoßen würde, aber dies scheint das erwartete Ergebnis zu liefern, da der Befehl nun sofort erfolgreich zurückgegeben wird.
Meine Frage ist:Gibt es bekannte, praktische und falsche Nebeneffekte beim Verknüpfen /dev/randomauf /dev/urandomLinux-Systemen, wie es auf FreeBSD-Systemen standardmäßig erfolgt?Oder könnte man sich vorstellen, dies dauerhaft festzulegen (beispielsweise in einem Skript am Ende des Startvorgangs), falls es aufgrund der /dev/randomSperrung eines Dienstes immer wieder zu Problemen kommt?
Antwort1
SehenMythen ü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 ist, wenn es geklont und als mehrere VMs ausgeführt wird, ohne den gespeicherten Entropiepool nach dem Klonen zurückzusetzen. Das ist ein Sonderfall, der nichts mit dem zu tun hat, was Sie wollen.
Antwort2
Der Unterschied besteht darin /dev/random, dass die Ausgabe gestoppt wird, nachdem der Entropiepool verwendet wurde. Versuchen Sie Folgendes:
$ cat /dev/random
(a few short lines of gibberish)^C
$
/dev/urandomFür die Fortsetzung der Ausgabe wird jedoch derselbe Pool wiederverwendet, wie hier gezeigt:
$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$
(Wenn Sie versuchen, diese speziellen Geräte zu caten, wird Ihre Eingabeaufforderung möglicherweise durcheinander gebracht. Geben Sie einfach ein resetund drücken Sie die Eingabetaste. Ihr Terminal wird dann wieder normal angezeigt.)
Verwenden Sie es /dev/urandom, wenn Sie etwas nur mit einem konstanten Fluss „zufälliger“ Bits füllen müssen. Verwenden Sie es /dev/randomfür Schlüssel, die absolut zufällig sein müssen.
Antwort3
Unter Linux /dev/randomliefert es Zufallsbits hoher Qualität. Sie stammen aus Quellen, dienichtvorhersehbar undnichtwiederholbar, außerhalb der Maschine. Im Gegensatz dazu /dev/urandomverwendet es die gleichen Zufallsdaten wie /dev/random(falls vorhanden), wenn es keine gibt, verwendet es einen Pseudozufallszahlengenerator, derdeterministischFür die meisten Zwecke ist es unvorhersehbar genug, abernichtfür sehr anspruchsvolle Anwendungen wie Kryptographie und viel weniger für die Erstellung langlebiger Schlüssel wie für GPG.