Larry Hastings:
> Just to confirm: that's a fresh Windows VM, never been booted before ever?  If it had ever been booted before, it might be saving its entropy pools to the hard disk at shutdown.

The VM was booted before. I don't see how I could schedule a task at boot, and then reboot... the new boot will obviously not be a "fresh VM".

Maybe it's possible to skip entropy written on disk on FreeBSD or Windows? If not, it confirms that the issue doesn't really affect FreeBSD and Windows in practice.

I read that OpenBSD is able to pass the entropy file through the boot loader. It is done before the kernel is loaded, so it doesn't matter when Python 3.5 is started, urandom will always be initialized after the first boot on OpenBSD, no? (If the first boot was able to produce enough entropy.) Maybe it's the same thing for FreeBSD.

Linux has a different design, loading the entropy file from the disk comes "later" in the init process, after the kernel booted. It's not done (currently) by the boot loader. It was discussed at:
http://bugs.python.org/issue26839#msg267853


> If you do the experiment a second time with another copy of the same fresh VM, does it generate the same 16 bytes?

From what I read, Windows is vulnerable the "reset" attack on the RNG when using a VM. So you can expect the same random numbers with your scenario.