This reminds me of an issue that (at one time, I'm not current on it) was an issue with OpenSSL in virtual environments.
When you restore a virtual machine snapshot, OpenSSL would maintain the entropy state from the snapshot. It apparently did not refresh it's userspace pool very often, so multiple VMs running the same snapshot would produce identical "random" numbers until OpenSSL refreshed from its entropy source. Yet another case of userspace PRNGs failing spectacularly. On Fri, May 29, 2015 at 10:50 AM, Russell Leidich <[email protected]> wrote: > On second thought, there is this particular case, wherein you would need > internally generated entropy: > > 1. You have a cloud server which has been compromised. > > 2. You issue a remote reboot, with the firmware instructed to boot from > the network. > > 3. In order to obtain the new OS image, the cloud server needs to do a key > exchange with a machine controlled by a human sysadmin. > > 4. However, to guard against replay attacks of a previous key exchange > (which could be used to reinstall the vulnerable OS), the child must create > a nonce. It cannot do this, absent local entropy. > > So in this particular scenario, unless the sysadmin can somehow walk over > to the cloud server, I think you are correct: local physical entropy is > required. > > Russell Leidich > > > >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
