Lesen aus dev / urandom - Systemverhalten

Aug 24 2020

Beim Lesen von beispielsweise dev/urandommit headoder ddwird natürlich erwartet, dass die Ausgabe immer zufällig und unterschiedlich ist.

Wie wird dies von UNIX auf niedrigem Niveau gehandhabt? Ist die Datei beim Lesen natürlich abgeschnitten oder ist die Datei tatsächlich eine Schnittstelle für eine symmetrische Verschlüsselung oder eine gleichwertige und als solche ist "Lesen" tatsächlich der Vorgang der Ausführung der Verschlüsselung.

Antworten

13 StephenKitt Aug 24 2020 at 21:15

/dev/urandomist ein Zeichengerät, keine reguläre Datei. Durch das Öffnen wird eine Schnittstelle zu einem Treiber bereitgestellt, normalerweise im Kernel, der Lesevorgänge verarbeitet. Jedes Mal, wenn ein Programm von liest /dev/urandom, wird der Treiber aufgerufen, und der Treiber bestimmt, wie der entsprechende Inhalt bereitgestellt wird (wie bei jedem anderen Zeichengerät - /dev/null, /dev/zero...).

Unter Linux ist dies in implementiert drivers/char/random.c. Es verwaltet einen „Entropiepool“, der aus verschiedenen Quellen zufälliger Daten stammt, und verarbeitet beim Lesen die Pooldaten mithilfe einer ChaCha-Stream-Verschlüsselung, um Daten für die Rückgabe zu erstellen.

8 Ángel Aug 24 2020 at 21:44

/dev/urandomist keine 'reguläre Datei' (ja, dies ist die POSIX-Benennung), sondern ein Gerät. Genau wie die meisten 'Dateien' auf / dev / hast du dort also viel magisches Verhalten.

  • Sie haben /dev/null, wo, egal wie viel Sie schreiben, es nie füllt
  • Sie haben zufällig / urandom / srandom und geben jedes Mal zufällig unterschiedliche Daten an
  • Sie haben /dev/tty(und Kollegen), wo Sie mit einem Terminal interagieren
  • Sie haben /dev/fullimmer "Kein Speicherplatz mehr auf dem Gerät" für einen Schreibversuch zurückgegeben
  • Sie haben /dev/zeroeine unendliche Menge von Null-Bytes

und viele mehr.

Diese Dateien sind eigentlich eine Schnittstelle zur Interaktion mit einem Kernelmodul. Wenn Sie es also "lesen", führt es tatsächlich eine Funktion aus, die aufgefordert wird, so viele Bytes zu lesen, wie Ihr Programm (head, dd usw.) angefordert hat ( /dev/urandomist ein Zeichengerät ). Diese Funktion behandelt es dann intern (basierend auf mehreren Entropiepools), um diesen Puffer zu füllen (in diesem Fall, damit Sie pseudozufällige Inhalte erhalten).