Perché farlo, in primo luogo. Abbiamo bisogno di "preservare" il seme casuale tra i riavvii? Cosa succederebbe se non lo facessimo? Il computer avrà 0 casualità all'avvio?
Questa risulta essere una domanda molto più profonda di quanto potresti realizzare. Cercherò di renderle giustizia senza scrivere un libro di testo.
Fondamentalmente:i computer fanno schifo alla casualità; quando hai una vera casualità (nota anche come entropia), è una buona idea mantenerla.
Supponiamo che il tuo computer non abbia un generatore di numeri casuali hardware. (I moderni chip Intel hanno il rdrand istruzione che attinge a un rng hardware, ma per ragioni politiche il kernel di Linux non lo usa.)
All'avvio, da dove prende il kernel la pura casualità? Secondo Wikipedia:
Il kernel Linux genera entropia dai tempi della tastiera, dai movimenti del mouse e dai tempi dell'IDE e rende i dati dei caratteri casuali disponibili ad altri processi del sistema operativo attraverso i file speciali /dev/random e /dev/urandom. Questa funzionalità è stata introdotta in Linux versione 1.3.30.
Quindi mouse, tastiera e temporizzazione degli eventi IO del disco rigido. Supponiamo che tu abbia bisogno di entropia durante l'avvio del sistema operativo (ad esempio, avvii sshd che deve generare le chiavi al suo primo avvio), non hai ancora caricato i driver del mouse e della tastiera e che all'inizio del ciclo di avvio non avrai effettuato molte chiamate IO su disco -- diavolo, abbastanza presto nel boot il kernel è ancora in esecuzione in una RAM FS, e anche dopo potresti trovarti su un SSD o un'unità flash con tempi di IO molto prevedibili.
Quindi torniamo alla tua domanda:
Cosa succederebbe se non lo facessimo? Il computer avrà 0 casualità all'avvio?
È possibile.
Su piccoli dispositivi Linux embedded come i router che si avviano dalla memoria flash (sia quelli domestici che quelli dei grandi data center che alimentano Internet), questo è in realtà un problema serio.
Per una fantastica lettura su questo argomento, consulta il documento del 2012 Mining Your Ps and Qs:Detection of Widespread Weak Keys in Network Devices che ha la scioccante scoperta che
Lo 0,75% dei certificati TLS [su Internet] condivide le chiavi a causa dell'entropia insufficiente durante la generazione delle chiavi.
Solo poche righe sotto il Short-Description hai citato, /etc/init.d/urandom rileva alcuni presupposti sulla segretezza:
## Assumption 1: We assume [/var/lib/urandom/random-seed] is a file (or a symlink
## to a file) that resides on a non-volatile medium that persists
## across reboots.
## Case 1a: Ideally, it is readable and writeable. Its is unshared,
## i.e. its contents are unique to this machine. It is protected so
## that its contents are not known to attackers.
## Case 1b: Less than ideally, it is read-only. Its contents are
## unique to this machine and not known to attackers.
Più avanti in quel file, dove il seme è scritto su disco, c'è un commento:
# see documentation in linux/drivers/char/random.c
che vale la pena leggere ma include:
* When any operating system starts up, it will go through a sequence
* of actions that are fairly predictable by an adversary, especially
* if the start-up does not involve interaction with a human operator.
* This reduces the actual number of bits of unpredictability in the
* entropy pool below the value in entropy_count. In order to
* counteract this effect, it helps to carry information in the
* entropy pool across shut-downs and start-ups.
... Even with
* complete knowledge of the start-up activities, predicting the state
* of the entropy pool requires knowledge of the previous history of
* the system.
Il risparmio di entropia tra i riavvii è una soluzione imperfetta alla carenza di entropia all'avvio. Perché imperfetto? In primo luogo, poiché l'entropia salvata è rilevabile, se un potenziale aggressore riuscisse a impossessarsi di quel seme salvato, potrebbe anche compromettere tutti i generatori di numeri casuali seminati con esso. In secondo luogo, perché quando il sistema viene ripristinato dai backup o da più istanze VM generate con lo stesso seme salvato, riutilizzerebbero tutte la stessa entropia salvata.
Tuttavia, tali disastri sono ancora preferibili alla mancanza di entropia all'avvio disponibile per il tuo sistema.
Tieni presente che, se configuri per risparmiare entropia, la tua soluzione non sarà certificabile, poiché FIPS e praticamente qualsiasi altro standard relativo a criptovalute e infosec vieta questa pratica.