Entropy se requiere en el siguiente sentido: si un PRNG tiene solo n bits de entropía, esto significa que tiene (conceptualmente) solo 2 < em> n posibles estados internos, y por lo tanto, podrían romperse mediante la enumeración brutal de estos 2 estados n , siempre que n es lo suficientemente bajo para que tal ataque de fuerza bruta sea factible.
Entonces las cosas se vuelven complejas, porque el "nivel de entropía" informado por el kernel NO es la entropía. No del que hablo más arriba.
Desde un punto de vista criptográfico , el algoritmo que calcula la salida de /dev/random y /dev/urandom es a (supuestamente) PRNG criptográficamente seguro . Lo que importa para la seguridad práctica es, de hecho, la entropía acumulada del estado interno. Salvo debilidades criptográficas en ese PRNG (no se conoce ninguna en este momento), la entropía solo puede aumentar o permanecer constante a lo largo del tiempo. De hecho, la "entropía" también se puede llamar "aquello que el atacante no sabe" y si el PRNG es criptográficamente seguro, entonces, por definición, la observación de gigabytes de producción solo produce información insignificante en el estado interno. Eso es lo que significa criptográficamente seguro .
Por lo tanto, si /dev/urandom tenía 200 bits de entropía en algún momento desde el último arranque, entonces still tiene 200 bits de entropía, o incluso más.
Desde el punto de vista de quien haya escrito ese código (y la temida página de manual correspondiente), la entropía se "agota" con el uso. Esta es la postura de alguien que asume, por el bien del argumento, que el PRNG no es no criptográficamente seguro, y de hecho es de alguna manera equivalente a simplemente emitir el estado interno tal como está. Desde ese punto de vista, si /dev/random comenzó con n bits de entropía y produce k bits, entonces ahora tiene nk bits de entropía .
Sin embargo, este punto de vista no es en última instancia sostenible, ya que si bien se basa en la suposición de que el PRNG está completamente roto y no funciona, también se basa en también , al mismo tiempo , en el supuesto de que el PRNG todavía es criptográficamente lo suficientemente seguro como para convertir la "entropía del hardware" (las fuentes de los elementos de datos que se supone que son algo aleatorios) en una buena secuencia uniforme de bits. En pocas palabras, la noción de agotamiento de la entropía funciona solo mientras asumamos la suposición extrema de que el PRNG es completamente débil, pero bajo este supuesto, la estimación de cuánta es realmente la entropía está completamente errada.
En esencia, ese punto de vista es contradictorio. Desafortunadamente, /dev/random implementa una estrategia de bloqueo que se basa en esta estimación de entropía defectuosa, lo cual es bastante inconveniente.
/dev/urandom nunca bloquea , independientemente de la cantidad de "entropía de hardware" que se haya recopilado desde el último arranque. Sin embargo, en las instalaciones "normales" de Linux, se inserta una semilla aleatoria al principio del proceso de arranque; esa semilla se guardó en el arranque anterior y se renueva inmediatamente después de la inserción. Esa semilla en su mayoría extiende la entropía de /dev/urandom a través de reinicios. Así que la afirmación se convierte en: si /dev/urandom tenía 200 bits de entropía en algún momento desde que se instaló el sistema operativo , entonces todavía tiene 200 bits de entropía.
Este comportamiento aún puede ser un poco problemático para algunos casos específicos, por ejemplo, arranque sin disco. La máquina de arranque puede necesitar cierta aleatoriedad antes para tener acceso a sus archivos (por ejemplo, para establecer un IPsec contexto necesario para llegar al servidor que contiene dichos archivos). Una mejor implementación de /dev/urandom se bloquearía hasta que se haya reunido una cantidad suficiente de entropía de hardware (por ejemplo, 128 bits), pero luego produciría bits "para siempre", sin implementar algún tipo de agotamiento de entropía. Esto es precisamente lo que hace /dev/urandom de FreeBSD. Y esto es bueno.
Resumen: no te preocupes. Si el PRNG utilizado en el kernel es criptográficamente seguro, como parece ser, entonces el recuento de "entropy_avail" no tiene sentido. Si el PRNG utilizado en el kernel es no criptográficamente seguro, entonces el recuento de "entropy_avail" es todavía defectuoso, y usted está en graves problemas de todos modos.
Tenga en cuenta que las instantáneas de VM rompen la entropía, ya que el comportamiento de la VM después de la restauración siempre funcionará en el estado que se guardó en la instantánea, y divergirá solo a través de la acumulación de eventos de hardware nuevos (lo que puede ser complicado en una VM, ya que el hardware de la VM no es verdadero hardware). El contador "entropy_avail" del kernel y el comportamiento de bloqueo de /dev/random , cambian nada a eso. Las instantáneas / restauraciones de VM son una vulnerabilidad de seguridad mucho más plausible para el PRNG del sistema que el escenario académico, puramente teórico que "entropy_avail" intenta capturar (y en realidad no logra).