Wann sollte /dev/random vs. /dev/urandom verwendet werden?

Soll ich /dev/random verwenden oder /dev/urandom ?

In welchen Situationen würde ich eines dem anderen vorziehen?

Akzeptierte Antwort:

TL;DR

Verwenden Sie /dev/urandom für die meisten praktischen Zwecke.

Die längere Antwort hängt von der Unix-Variante ab, die Sie verwenden.

Linux

Historisch gesehen /dev/random und /dev/urandom gleichzeitig eingeführt.

Wie @DavidSchwartz in einem Kommentar betonte, mit /dev/urandom wird in den allermeisten Fällen bevorzugt. Er und andere stellten auch einen Link zu den ausgezeichneten Mythen über /dev/urandom bereit Artikel, den ich zum Weiterlesen empfehle.

Zusammengefasst:

• Die Manpage ist irreführend.
• Beide werden vom gleichen gespeist CSPRNG zur Generierung von Zufälligkeit (Diagramme 2 und 3)
• /dev/random blockiert, wenn ihm die Entropie ausgeht,
  also aus /dev/random lesen kann die Prozessausführung anhalten.
• Die Entropiemenge wird konservativ geschätzt, aber nicht gezählt
• /dev/urandom wird niemals blockieren.
• In seltenen Fällen hat das CSPRNG sehr kurz nach dem Booten möglicherweise nicht genug Entropie gehabt, um richtig geseedet zu werden und /dev/urandom erzeugt möglicherweise keine qualitativ hochwertige Zufälligkeit.
• Niedrige Entropie ist kein Problem, wenn das CSPRNG anfangs richtig gesät wurde.
• Das CSPRNG wird ständig neu gesetzt.
• In Linux 4.8 und höher, /dev/urandom erschöpft nicht den Entropiepool (verwendet von /dev/random ), verwendet aber die CSPRNG-Ausgabe von Upstream.
• Verwenden Sie /dev/urandom .

Ausnahmen von der Regel

Im Cryptography Stack Exchange’s When to use /dev/random über /dev/urandom unter Linux gibt @otus zwei Anwendungsfälle:

1. Kurz nach dem Booten auf einem Gerät mit niedriger Entropie, wenn noch nicht genug Entropie generiert wurde, um /dev/urandom richtig zu starten .

2. Generieren eines One-Time-Pads mit informationstheoretischer Sicherheit

Wenn Sie sich wegen (1) Sorgen machen, können Sie die verfügbare Entropie in /dev/random überprüfen .

Wenn du (2) machst, weißt du es bereits 🙂

Hinweis:Sie können prüfen, ob das Lesen von /dev/random blockiert, aber achten Sie auf mögliche Race-Conditions.

Alternative:Keines von beiden verwenden!

@otus wies auch darauf hin, dass getrandom() Das System liest aus /dev/urandom und nur blockieren, wenn die anfängliche Seed-Entropie nicht verfügbar ist.

Es gibt Probleme beim Ändern von /dev/urandom um getrandom() zu verwenden , aber es ist denkbar, dass ein neues /dev/xrandom Das Gerät wird basierend auf getrandom() erstellt .

macOS

Es spielt keine Rolle, wie Wikipedia sagt:

macOS verwendet 160-Bit-Yarrow basierend auf SHA1. Es gibt keinen Unterschied zwischen /dev/random und /dev/urandom; beide verhalten sich identisch. Apples iOS verwendet auch Yarrow.

FreeBSD

Es spielt keine Rolle, wie Wikipedia sagt:

/dev/urandom ist nur ein Link zu /dev/random und blockiert nur bis zur richtigen Aussaat.

Das bedeutet, dass FreeBSD nach dem Booten schlau genug ist, zu warten, bis genügend Seed-Entropie gesammelt wurde, bevor es einen endlosen Strom zufälliger Güte liefert.

Siehe auch:Linux – Wie bringt man Oracle Java 7 dazu, mit setcap cap_net_bind_service+ep zu arbeiten?

NetBSD

Verwenden Sie /dev/urandom , vorausgesetzt, Ihr System hat mindestens einmal von /dev/random gelesen um eine ordnungsgemäße anfängliche Aussaat sicherzustellen.

Die rnd(4)-Manpage sagt:

/dev/urandom blockiert nie.

/dev/random blockiert manchmal. Blockiert früh beim Booten, wenn der Zustand des
Systems vorhersehbar ist.

Anwendungen sollten aus /dev/urandom gelesen werden wenn sie zufällig
generierte Daten benötigen, z.B. kryptografische Schlüssel oder Seeds für Simulationen.

Systeme sollten so konstruiert sein, dass sie vernünftigerweise mindestens einmal von /dev/random lesen beim Booten, bevor Dienste ausgeführt werden, die mit dem
Internet kommunizieren oder anderweitig Kryptografie benötigen, um zu vermeiden, dass Schlüssel
vorhersehbar generiert werden.