At 10:38 PM +0300 8/2/10, Yaron Sheffer wrote:
the interesting thread on seeding and reseeding /dev/random did not mention
that many of the most problematic systems in this respect are virtual
machines. Such machines (when used for cloud computing) are not only
servers, so have few sources of
On Mon, 02 Aug 2010, Yaron Sheffer wrote:
the interesting thread on seeding and reseeding /dev/random did not
mention that many of the most problematic systems in this respect
are virtual machines. Such machines (when used for cloud
Any decent hypervisor can supply entropy to the VMs. For
On Mon, 2 Aug 2010, Yaron Sheffer wrote:
In addition to the mitigations that were discussed on the list, such machines
could benefit from seeding /dev/random (or periodically reseeding it) from
the *host machine's* RNG. This is one thing that's guaranteed to be different
between VM instances.
Hi,
we are using haveged in our VMs to feed the random pool and
it seems to work good (means: statistical verification of
the output looks good, nearly 0 entropy overestimation, but
we never correlated output from cloned VMs).
I assume feeding the VMs from the host system can be problematic
On Mon, 2 Aug 2010 20:17:42 -0300 Henrique de Moraes Holschuh
h...@debian.org wrote:
Desktops with live-CDs and half-assed embedded boxes that lack a
TRNG are the real problem.
I'm not sure what to do about the live CD problem, but in a previous
iteration of this discussion a couple of years
On Mon, 02 Aug 2010, Paul Wouters wrote:
On Mon, 2 Aug 2010, Yaron Sheffer wrote:
In addition to the mitigations that were discussed on the list,
such machines could benefit from seeding /dev/random (or
periodically reseeding it) from the *host machine's* RNG. This is
one thing that's
Hi,
the interesting thread on seeding and reseeding /dev/random did not
mention that many of the most problematic systems in this respect are
virtual machines. Such machines (when used for cloud computing) are
not only servers, so have few sources of true and hard-to-observe
entropy. Often