search for: virrandombits

...are not linked with gnutls), then we should prefer the new Linux syscall but fall back to /dev/urandom for JUST enough bits for a seed; once we're seeded, stick with using our existing PRNG for all future bits (after all, we aren't trying to generate cryptographically secure keys using virRandomBits - and the places where we DO need crypto-strong randomness such as setting up TLS migration is where we are relying on gnutls to provide it rather than virRandomBits). So at this point, it's just a matter of someone writing the patches. -- Eric Blake, Principal Software Engineer Red Hat, I...

...en we should >> prefer the new Linux syscall but fall back to /dev/urandom for JUST >> enough bits for a seed; once we're seeded, stick with using our existing >> PRNG for all future bits (after all, we aren't trying to generate >> cryptographically secure keys using virRandomBits - and the places where >> we DO need crypto-strong randomness such as setting up TLS migration is >> where we are relying on gnutls to provide it rather than virRandomBits). >> >> So at this point, it's just a matter of someone writing the patches. >> > > Ac...

...;>> prefer the new Linux syscall but fall back to /dev/urandom for JUST >>> enough bits for a seed; once we're seeded, stick with using our existing >>> PRNG for all future bits (after all, we aren't trying to generate >>> cryptographically secure keys using virRandomBits - and the places where >>> we DO need crypto-strong randomness such as setting up TLS migration is >>> where we are relying on gnutls to provide it rather than virRandomBits). >>> >>> So at this point, it's just a matter of someone writing the patches. >&g...

...ll but fall back to /dev/urandom for JUST > > > > > enough bits for a seed; once we're seeded, stick with using our existing > > > > > PRNG for all future bits (after all, we aren't trying to generate > > > > > cryptographically secure keys using virRandomBits - and the places where > > > > > we DO need crypto-strong randomness such as setting up TLS migration is > > > > > where we are relying on gnutls to provide it rather than virRandomBits). > > > > > > > > > > So at this point, it's jus...

...efer the new Linux syscall but fall back to /dev/urandom for JUST >>>> enough bits for a seed; once we're seeded, stick with using our existing >>>> PRNG for all future bits (after all, we aren't trying to generate >>>> cryptographically secure keys using virRandomBits - and the places where >>>> we DO need crypto-strong randomness such as setting up TLS migration is >>>> where we are relying on gnutls to provide it rather than virRandomBits). >>>> >>>> So at this point, it's just a matter of someone writing the...

...ked with gnutls), then we should >prefer the new Linux syscall but fall back to /dev/urandom for JUST >enough bits for a seed; once we're seeded, stick with using our existing >PRNG for all future bits (after all, we aren't trying to generate >cryptographically secure keys using virRandomBits - and the places where >we DO need crypto-strong randomness such as setting up TLS migration is >where we are relying on gnutls to provide it rather than virRandomBits). > >So at this point, it's just a matter of someone writing the patches. > Actually, do we need to have a fall...

...om for JUST > > > > > > > enough bits for a seed; once we're seeded, stick with using our existing > > > > > > > PRNG for all future bits (after all, we aren't trying to generate > > > > > > > cryptographically secure keys using virRandomBits - and the places where > > > > > > > we DO need crypto-strong randomness such as setting up TLS migration is > > > > > > > where we are relying on gnutls to provide it rather than virRandomBits). > > > > > > > > > > > > &...

...back to /dev/urandom for JUST >> > > > > enough bits for a seed; once we're seeded, stick with using our existing >> > > > > PRNG for all future bits (after all, we aren't trying to generate >> > > > > cryptographically secure keys using virRandomBits - and the places where >> > > > > we DO need crypto-strong randomness such as setting up TLS migration is >> > > > > where we are relying on gnutls to provide it rather than virRandomBits). >> > > > > >> > > > > So at this poin...

Reviving an ancient thread: On 11/04/2014 02:18 AM, Daniel P. Berrange wrote: > On Mon, Nov 03, 2014 at 11:09:12AM -0500, Brian Rak wrote: >> I just ran into an issue where I had about 30 guests get duplicate mac >> addresses assigned. These were scattered across 30 different machines. >> >> Some debugging revealed that: >> >> 1) All the host machines were

On Mon, Nov 03, 2014 at 11:09:12AM -0500, Brian Rak wrote: > I just ran into an issue where I had about 30 guests get duplicate mac > addresses assigned. These were scattered across 30 different machines. > > Some debugging revealed that: > > 1) All the host machines were restarted within a couple seconds of each > other > 2) All the host machines had fairly similar

On 05/25/2018 02:58 PM, Eric Blake wrote: > Reviving an ancient thread: > > On 11/04/2014 02:18 AM, Daniel P. Berrange wrote: >> On Mon, Nov 03, 2014 at 11:09:12AM -0500, Brian Rak wrote: >>> I just ran into an issue where I had about 30 guests get duplicate mac >>> addresses assigned.  These were scattered across 30 different machines. >>> >>>

I just ran into an issue where I had about 30 guests get duplicate mac addresses assigned. These were scattered across 30 different machines. Some debugging revealed that: 1) All the host machines were restarted within a couple seconds of each other 2) All the host machines had fairly similar libvirtd pids (within ~100 PIDs of each other) 3) Libvirt seeds the RNG using 'time(NULL) ^