Le macchine virtuali hanno hardware virtuale, ma questo non significa necessariamente che siano completamente prive di fonti di entropia. In particolare interrupt: mentre la VM non ha un vero generatore di interrupt, il suo sistema operativo continua a ricevere tali "interrupt" come parte dell'emulazione dell'hardware. Ad esempio, quando ci si connette alla VM tramite, ad esempio, SSH, i pacchetti di rete continuano a scorrere avanti e indietro e ciascun pacchetto in ingresso attiva un interrupt emulato nella VM. L'entropia derivata dal kernel da tale interrupt proviene dall'ora esatta di comparsa di quell'interrupt, che, in questo caso, è una funzione dell'arrivo reale del pacchetto sull'interfaccia di rete fisica del sistema host. Il processo dal pacchetto in entrata all'interrupt è più complicato rispetto a una macchina non virtuale, poiché l'host e il livello VM si trovano in mezzo, ma l'entropia dal mondo fisico è ancora resa disponibile per il kernel VM.
Un problema molto più pressante per VM e casualità è Clonazione VM . Potrebbe essere necessario installare e configurare una VM completa, quindi creare un'istantanea e clonarla per creare facilmente diverse nuove VM già configurate. Sfortunatamente, questo significa che tutti i cloni partono dallo stesso identico stato interno di RNG. Una volta avviati, iniziano a divergere man mano che ciascuno accumula i propri "eventi casuali" (anche se l'hardware è emulato, gli eventi hardware emulati derivano ancora indirettamente da veri eventi casuali dell'hardware, come spiegato sopra). La divergenza potrebbe essere lenta in termini di calcolo (potrebbe richiedere diversi secondi, e questo è molto lungo per i computer che possono fare miliardi di operazioni al secondo).
Il metodo più completo per risolvere il problema consiste nell'imporre la casualità seminando ogni VM con un seme ottenuto da un'altra fonte casuale altrove; questo è facile come scrivere un file in /dev/random . Questo potrebbe essere utile se cloni VM; altrimenti, questo è probabilmente inutile (ma non danneggerà comunque). Nota che questo è necessario solo una volta per VM: le normali distribuzioni Linux genereranno e salveranno un "seed file" all'arresto e lo riutilizzeranno al prossimo avvio, quindi una volta che una VM è stata seminata, rimane seminata.
Per quanto riguarda la tua soluzione # 2, prendi nota che la differenza tra /dev/random e /dev/urandom (in Linux) non è esattamente ciò che affermi. /dev/random bloccherà se stima che il suo pool interno non ha abbastanza entropia; ma considera anche che il suo pool è impoverito dopo l'uso. Il blocco prima che sia stata raccolta abbastanza entropia va bene; ma l '"effetto di esaurimento" implica un blocco molto più ampio, e quello ha solo basi scientifiche molto fragili. È un difetto noto del /dev/random di Linux. Un comportamento molto più sano è quello che ottieni con /dev/random di FreeBSD (e, per estensione, Mac OS X): quello si bloccherà finché non sarà stata raccolta abbastanza entropia iniziale , quindi produrrà tanti byte come desideri con un PRNG crittograficamente sicuro, senza bloccare. Nota che FreeBSD /dev/random e /dev/urandom sono completamente identici (e questo è buono).
Comunque, anche il comportamento maniacale di /dev/random di Linux per quanto riguarda l'esaurimento dell'entropia sarà ingannato dalla clonazione VM. Insistere sulla generazione di chiavi con /dev/random non solo ti farà aspettare tempi eccessivi; potrebbe anche non riuscire a raggiungere il livello desiderato di casualità in presenza della clonazione VM.
Per riassumere, la tua soluzione n. 3 è quella giusta.