search for: virrandombit

Displaying 12 results from an estimated 12 matches for "virrandombit".

Did you mean: virrandombits
2018 May 25
2
Re: virRandomBits - not very random
...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,...
2018 May 29
2
Re: [libvirt] virRandomBits - not very random
...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. >> > > A...
2018 May 29
0
Re: [libvirt] virRandomBits - not very random
...;>> 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. >&...
2018 Jun 01
0
Re: [libvirt] virRandomBits - not very random
...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 ju...
2018 May 30
2
Re: [libvirt] virRandomBits - not very random
...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 th...
2018 May 29
0
Re: [libvirt] virRandomBits - not very random
...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 fal...
2018 Jun 01
0
Re: [libvirt] virRandomBits - not very random
...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). > > > > > > > > > > > >...
2018 Jun 01
2
Re: [libvirt] virRandomBits - not very random
...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 poi...
2018 May 25
3
Re: virRandomBits - not very random
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
2014 Nov 04
0
Re: virRandomBits - not very random
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
2018 May 25
0
Re: virRandomBits - not very random
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. >>> >>>
2014 Nov 03
2
virRandomBits - not very random
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) ^