Las máquinas virtuales tienen hardware virtual, pero esto no significa necesariamente que estén completamente desprovistas de fuentes de entropía. En particular, las interrupciones: mientras que la máquina virtual no tiene un hardware de generador de interrupciones real, su sistema operativo todavía recibe tales "interrupciones" como parte de la emulación de hardware. Por ejemplo, cuando se conecta a su VM a través de SSH, digamos, los paquetes de red todavía fluyen de un lado a otro, y cada paquete entrante desencadena una interrupción emulada en la VM. La entropía derivada por el núcleo de tal interrupción proviene de la hora exacta de aparición de esa interrupción, que, en este caso, es una función de la llegada real del paquete a la interfaz de red física del sistema host. El proceso desde el paquete entrante hasta la interrupción es más complejo que en una máquina no virtual, ya que el host y la capa de VM se encuentran en el medio, pero la entropía del mundo físico todavía está disponible para el núcleo de la VM.
Un problema mucho más acuciante para VM y aleatoriedad es clonación de VM . Es posible que desee instalar y configurar una máquina virtual completa, luego hacer una instantánea y clonarla para crear fácilmente varias máquinas virtuales nuevas ya configuradas. Desafortunadamente, esto significa que todos los clones comienzan exactamente desde el mismo estado interno de RNG. Una vez que se inician, comienzan a divergir a medida que cada uno acumula sus propios "eventos aleatorios" (aunque el hardware es emulado, los eventos de hardware emulados aún provienen indirectamente de eventos aleatorios de hardware real, como se explicó anteriormente). La divergencia puede ser lenta en términos de computación (puede tardar varios segundos, y eso es muy largo para computadoras que pueden hacer miles de millones de operaciones por segundo).
El método más completo para corregir eso es hacer cumplir la aleatoriedad sembrando cada VM con una semilla obtenida de alguna otra fuente aleatoria en otro lugar; Esto es tan fácil como escribir un archivo en /dev/random . Esto puede ser deseable si clona VM; de lo contrario, esto probablemente sea inútil (pero no dañará de todos modos). Tenga en cuenta que esto es necesario solo una vez por VM: las distribuciones normales de Linux generarán y guardarán un "archivo semilla" al apagarse y reutilizarlo en el próximo arranque, por lo que una vez que se haya sembrado una máquina virtual, se mantendrá sin datos.
En cuanto a su solución # 2, tenga en cuenta que la diferencia entre /dev/random y /dev/urandom (en Linux) no es exactamente lo que indica. /dev/random bloqueará si estima que su grupo interno no tiene suficiente entropía; pero también considera que su grupo está agotado al usarlo. El bloqueo antes de que se haya reunido suficiente entropía está bien; pero el "efecto de agotamiento" implica mucho más bloqueo, y ese solo tiene una base científica muy débil. Es un defecto conocido de /dev/random de Linux. Un comportamiento mucho más sensato es lo que obtienes con /dev/random de FreeBSD (y, por extensión, Mac OS X): ese bloque se bloqueará hasta que se haya reunido suficiente entropía inicial , y luego se producirán tantos bytes Como desee con un PRNG criptográficamente seguro, sin bloqueo. Tenga en cuenta que FreeBSD /dev/random y /dev/urandom son completamente idénticos (y esto es bueno).
De todos modos, incluso el comportamiento maniaco de /dev/random de Linux con respecto al agotamiento de la entropía será engañado por la clonación de máquinas virtuales. Por lo tanto, insistir en generar claves con /dev/random no solo hará que esperes cantidades desordenadas de tiempo; También puede fallar en alcanzar el nivel deseado de aleatoriedad en presencia de la clonación de máquinas virtuales.
Para resumir, tu solución # 3 es la correcta.