¿Por qué hacer eso en absoluto, en primer lugar. ¿Necesitamos "preservar" la semilla aleatoria entre reinicios? ¿Qué pasaría si no lo hacemos? ¿La computadora tendrá 0 aleatoriedad cuando arranque?
Esta resulta ser una pregunta mucho más profunda de lo que te imaginas. Intentaré hacerle justicia sin escribir un libro de texto.
Básicamente:las computadoras apestan a la aleatoriedad; cuando tienes cierta aleatoriedad verdadera (también conocida como entropía), es una buena idea aferrarse a ella.
Supongamos que su computadora no tiene un generador de números aleatorios de hardware. (Los chips Intel modernos tienen el rdrand instrucción que aprovecha un rng de hardware, pero por razones políticas, el kernel de Linux no lo usa).
En el arranque, ¿de dónde obtiene el kernel pura aleatoriedad? Según Wikipedia:
El kernel de Linux genera entropía a partir de los tiempos del teclado, los movimientos del mouse y los tiempos del IDE y pone los datos de caracteres aleatorios a disposición de otros procesos del sistema operativo a través de los archivos especiales /dev/random y /dev/urandom. Esta capacidad se introdujo en la versión 1.3.30 de Linux.
Por lo tanto, el mouse, el teclado y la sincronización de los eventos de E/S del disco duro. Digamos que necesita entropía durante el arranque del sistema operativo (por ejemplo, inicia sshd que necesita generar claves en su primer inicio), aún no ha cargado los controladores del mouse y del teclado, y al principio del ciclo de arranque no habrá realizado muchas llamadas de E/S de disco, diablos, lo suficientemente temprano en el arranque el kernel aún se ejecuta en un FS de RAM, e incluso después de eso, es posible que esté en un SSD o una unidad flash que tiene tiempos de E/S muy predecibles.
Volviendo a tu pregunta:
¿Qué pasaría si no lo hacemos? ¿La computadora tendrá 0 aleatoriedad cuando arranque?
Es posible.
En pequeños dispositivos Linux integrados, como enrutadores que arrancan desde la memoria flash (tanto los pequeños domésticos como los de los grandes centros de datos que alimentan Internet), esto es realmente un problema grave.
Para una lectura impresionante sobre este tema, consulte el artículo de 2012 Extracción de sus Ps y Qs:Detección de claves débiles generalizadas en dispositivos de red que tiene el impactante descubrimiento de que
El 0,75 % de los certificados TLS [en Internet] comparten claves debido a una entropía insuficiente durante la generación de claves.
Solo unas pocas líneas debajo del Short-Description citaste, /etc/init.d/urandom señala algunas suposiciones sobre el secreto:
## 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.
Más adelante en ese archivo, donde la semilla se escribe en el disco, hay un comentario:
# see documentation in linux/drivers/char/random.c
que vale la pena leer pero incluye:
* 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.
Ahorrar entropía entre reinicios es una solución imperfecta para la escasez de entropía durante el arranque. ¿Por qué imperfecto? Primero, debido a que la entropía guardada es detectable, si un atacante potencial pudiera obtener esa semilla guardada, también podría comprometer todos los generadores de números aleatorios sembrados con ella. En segundo lugar, porque cuando el sistema se restaura a partir de copias de seguridad o varias instancias de VM generadas con la misma semilla guardada, todas reutilizarían la misma entropía guardada.
Aún así, estos desastres siguen siendo preferibles a no tener entropía de tiempo de arranque disponible para su sistema.
Tenga en cuenta que si configura para ahorrar entropía, su solución no será certificable, ya que FIPS y prácticamente cualquier otro estándar relacionado con criptografía e infosec prohíbe esta práctica.