Habe ich / dev / urandom verstanden?

Ich habe darüber gelesen /dev/urandomund, soweit ich das beurteilen kann, /dev/randomkryptografisch zufällige Zahlen erstellt, indem ich verschiedene Ereignisse wie Netzwerkpaket-Timings usw. ausnutzte. Habe ich jedoch richtig verstanden, dass /dev/urandomein PRNG verwendet wird, das mit einer Zahl von gesetzt ist /dev/random? Oder wird es nur verwendet /dev/random, solange es Bits gibt - und wenn sie ausgehen, fällt es auf etwas PRNG mit einem Samen zurück, der von wo gesammelt wurde?

Aus der urandomManpage:

Der Zufallszahlengenerator sammelt Umgebungsgeräusche von Gerätetreibern und anderen Quellen in einem Entropiepool. Der Generator hält auch eine Schätzung der Anzahl von Rauschbits im Entropiepool. Aus diesem Entropiepool werden Zufallszahlen erstellt.

Beim Lesen gibt das Gerät / dev / random nur zufällige Bytes innerhalb der geschätzten Anzahl von Rauschbits im Entropiepool zurück. / dev / random sollte für Anwendungen geeignet sein, die eine Zufälligkeit von sehr hoher Qualität erfordern, wie z. B. einmaliges Pad oder Schlüsselgenerierung. Wenn der Entropiepool leer ist, werden Lesevorgänge aus / dev / random blockiert, bis zusätzliches Umgebungsgeräusch erfasst wird.

Ein Lesevorgang vom / dev / urandom-Gerät blockiert nicht das Warten auf weitere Entropie . Wenn im Entropiepool nicht genügend Entropie vorhanden ist, sind die zurückgegebenen Werte theoretisch anfällig für einen kryptografischen Angriff auf die vom Treiber verwendeten Algorithmen. Kenntnisse darüber, wie dies zu tun ist, sind in der aktuellen nicht klassifizierten Literatur nicht verfügbar, aber es ist theoretisch möglich, dass ein solcher Angriff existiert. Wenn dies in Ihrer Anwendung ein Problem darstellt, verwenden Sie stattdessen / dev / random.

Beide verwenden ein PRNG, obwohl die Verwendung von Umweltdaten und Entropiepools es astronomisch viel schwieriger macht, das PRNG zu knacken, und unmöglich ist, ohne genau dieselben Umweltdaten zu erfassen.

Als Faustregel gilt, dass es ohne spezielle teure Hardware, die Daten beispielsweise von Quantenereignissen sammelt, keinen echten Zufallszahlengenerator gibt (dh ein RNG, das wirklich unvorhersehbare Zahlen erzeugt). Für kryptografische Zwecke reicht jedoch / dev / random oder / dev / urandom aus (die verwendete Methode ist für einen CPRNG-Generator für kryptografische Pseudozufallszahlen).

Der Entropiepool und das blockierende Lesen von / dev / random werden als Schutz verwendet, um die Unmöglichkeit der Vorhersage der Zufallszahl sicherzustellen. Wenn beispielsweise ein Angreifer den Entropiepool eines Systems erschöpft hat, ist es möglich, obwohl dies mit der heutigen Technologie höchst unwahrscheinlich ist, dass er die Ausgabe von / dev / urandom vorhersagen kann, die seit langem nicht mehr neu ausgesät wurde (obwohl dies der Fall ist) Dazu müsste der Angreifer auch die Fähigkeit des Systems ausschöpfen, mehr Entropien zu sammeln, was auch astronomisch unwahrscheinlich ist.

Was Sie in der Praxis tatsächlich brauchen, ist das, was FreeBSD /dev/urandombietet: Es liest einen anfänglichen Startwert von ausreichender Länge aus /dev/randomund verwendet dann ein PRNG. Daher kann es anfänglich blockieren (unmittelbar nach dem Systemstart), aber sobald es genügend Entropie gesammelt hat, wird es nie blockiert. Dies bietet den Grad an Zufälligkeit, der von den meisten kryptografischen Protokollen benötigt wird, ohne übermäßig zu blockieren.

Linux /dev/urandomist ähnlich, mit der Ausnahme, dass es niemals blockiert und daher die Gefahr besteht, dass Zufälligkeiten von geringer Qualität zurückgegeben werden, wenn es direkt nach dem Start verwendet wird. Auf der anderen Seite /dev/randomkann auch lange nach dem Booten blockieren, was ebenfalls ein Problem ist. Ich habe oft gesehen, wie Server auf mysteriöse Weise blockiert wurden, weil einige Software darauf bestand, sie zu verwenden /dev/random, und der Server ohne Tastatur nicht genug Entropie bekam.

Die übliche Linux-Distribution speichert beim Herunterfahren einen zufälligen Startwert aus /dev/urandomund injiziert ihn beim nächsten Start wieder, wodurch die Qualität des von bereitgestellten Zufalls garantiert wird /dev/urandom. Nur während der Installation des Betriebssystems wird die kryptografische Qualität zu einem Problem, und normalerweise liegt dies nicht daran, dass die Installation eine Reihe von Interaktionen mit dem Menschen beinhaltet, der die Installation durchführt, was zu Horden von Entropie führt.

Zusammenfassend sollten Sie unter Linux und FreeBSD /dev/urandomnicht verwenden /dev/random.

Zitiert von hier

/dev/randomwird blockiert, nachdem der Entropiepool erschöpft ist. Es bleibt blockiert, bis zusätzliche Daten aus den verfügbaren Entropiequellen gesammelt wurden. Dies kann die zufällige Datengenerierung verlangsamen.

/dev/urandomwird nicht blockieren. Stattdessen wird der interne Pool wiederverwendet, um mehr Pseudozufallsbits zu erzeugen.

/dev/urandom wird am besten verwendet, wenn:

• Sie möchten nur eine große Datei mit zufälligen Daten für eine Art von Tests.
• Sie verwenden die dd Befehl löschen Sie Daten von einer Festplatte, indem Sie sie durch zufällige Daten ersetzen.
• Fast überall sonst, wo Sie keinen wirklich guten Grund haben, /dev/randomstattdessen zu verwenden .

/dev/random ist wahrscheinlich die bessere Wahl, wenn:

• Zufälligkeit ist entscheidend für die Sicherheit der Kryptografie in Ihrer Anwendung - einmalige Pads, Schlüsselgenerierung.