Lettura da dev / urandom - comportamento del sistema

Aug 24 2020

Quando si legge da dev/urandom, con diciamo heado dd, è ovviamente previsto che l'output sia sempre casuale e diverso.

Come viene gestito da UNIX a basso livello? Il file viene troncato naturalmente durante la lettura o invece è effettivamente un'interfaccia per un cifrario simmetrico o equivalente e come tale la "lettura" è effettivamente l'atto di eseguire il cifrario.

Risposte

13 StephenKitt Aug 24 2020 at 21:15

/dev/urandomè un dispositivo a caratteri, non un file normale. Aprendolo fornisce un'interfaccia a un driver, solitamente nel kernel, che gestisce le letture; ogni volta che un programma legge da /dev/urandom, viene effettuata una chiamata al driver, e il driver determina come fornire il contenuto appropriato (come qualsiasi altro dispositivo a caratteri - /dev/null, /dev/zero...).

Su Linux, questo è implementato in drivers/char/random.c. Mantiene un "pool di entropia", seminato da varie fonti di dati casuali e, quando viene letto, elabora i dati del pool utilizzando un cifrario a flusso ChaCha per costruire i dati da restituire.

8 Ángel Aug 24 2020 at 21:44

/dev/urandomnon è un "file normale" (sì, questa è la denominazione POSIX), è un dispositivo. Proprio come la maggior parte dei "file" su / dev / Quindi hai un sacco di comportamenti magici lì.

  • Hai /dev/null, dove non importa quanto scrivi, non si riempie mai
  • Hai random / urandom / srandom, fornendo in modo casuale dati diversi ogni volta
  • Hai /dev/tty(e colleghi) dove interagisci con un terminale
  • Hai /dev/fullche restituisce sempre "Nessuno spazio lasciato sul dispositivo" per qualsiasi tentativo di scrittura
  • Hai /dev/zeroche restituisce un insieme infinito di byte nulli

e molti altri.

Questi file sono in realtà un'interfaccia per interagire con un modulo del kernel. Quindi, quando lo 'leggi', in realtà sta eseguendo una funzione a cui viene chiesto di leggere quanti byte il tuo programma (head, dd, ecc.) Richiesto ( /dev/urandomè un dispositivo a caratteri ). Questa funzione quindi la gestisce internamente (in base a diversi pool di entropia) per riempire quel buffer (in questo caso, in modo da ottenere contenuti pseudocasuali).