Lettura da dev / urandom - comportamento del sistema
Quando si legge da dev/urandom
, con diciamo head
o 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
/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.
/dev/urandom
non è 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/full
che restituisce sempre "Nessuno spazio lasciato sul dispositivo" per qualsiasi tentativo di scrittura - Hai
/dev/zero
che 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).