On 05/25/2018 09:17 AM, Michal Privoznik wrote:>>> We should probably seed it with data from /dev/urandom, and/or the new >>> Linux getrandom() syscall (or BSD equivalent). > > I'm not quite sure that right after reboot there's going to be enough > entropy. Every service that's starting wants some random bits. But it's > probably better than what we have now.Here's where we left things last time it came up: https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html If gnutls has an interface that will give us random bits (gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of our random bits (and forget about a seed), except when we are mocking things in our testsuite, and need a deterministic PRNG from a deterministic seed. If not (including if we 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, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Martin Kletzander
2018-May-29 13:38 UTC
Re: [libvirt-users] [libvirt] virRandomBits - not very random
On Fri, May 25, 2018 at 09:37:44AM -0500, Eric Blake wrote:>On 05/25/2018 09:17 AM, Michal Privoznik wrote: > >>>> We should probably seed it with data from /dev/urandom, and/or the new >>>> Linux getrandom() syscall (or BSD equivalent). >> >> I'm not quite sure that right after reboot there's going to be enough >> entropy. Every service that's starting wants some random bits. But it's >> probably better than what we have now. > >Here's where we left things last time it came up: > >https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html > >If gnutls has an interface that will give us random bits >(gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of >our random bits (and forget about a seed), except when we are mocking >things in our testsuite, and need a deterministic PRNG from a >deterministic seed. > >If not (including if we 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. >Actually, do we need to have a fallback at all? Can't we just drop all the gross parts of the code the conditionally compile based on GNUTLS support? Why don't we have gnutls required?>-- >Eric Blake, Principal Software Engineer >Red Hat, Inc. +1-919-301-3266 >Virtualization: qemu.org | libvirt.org > >-- >libvir-list mailing list >libvir-list@redhat.com >https://www.redhat.com/mailman/listinfo/libvir-list
Michal Privoznik
2018-May-29 13:44 UTC
Re: [libvirt-users] [libvirt] virRandomBits - not very random
On 05/29/2018 03:38 PM, Martin Kletzander wrote:> On Fri, May 25, 2018 at 09:37:44AM -0500, Eric Blake wrote: >> On 05/25/2018 09:17 AM, Michal Privoznik wrote: >> >>>>> We should probably seed it with data from /dev/urandom, and/or the new >>>>> Linux getrandom() syscall (or BSD equivalent). >>> >>> I'm not quite sure that right after reboot there's going to be enough >>> entropy. Every service that's starting wants some random bits. But it's >>> probably better than what we have now. >> >> Here's where we left things last time it came up: >> >> https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html >> >> If gnutls has an interface that will give us random bits >> (gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of >> our random bits (and forget about a seed), except when we are mocking >> things in our testsuite, and need a deterministic PRNG from a >> deterministic seed. >> >> If not (including if we 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. >> > > Actually, do we need to have a fallback at all? Can't we just drop all the > gross parts of the code the conditionally compile based on GNUTLS > support? Why > don't we have gnutls required?That's exactly what I'm suggesting in my patches [1]. gnutls is widely available (including Linux, Windows, *BSD, Mac Os X). However, before doing that we need to fix virRandomBits() to actually call gnutls_rnd(). 1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html Michal