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
John Ferlan
2018-May-29 14:06 UTC
Re: [libvirt-users] [libvirt] virRandomBits - not very random
On 05/29/2018 09:44 AM, Michal Privoznik wrote:> 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 >I have this faint recollection of one of the CI platform builds failing because something in the gnutls* family didn't exist there when I was making the changes to add the domain master secret code.... After a bit of digging, it seems it was a perhaps a CENTOS6 environment: https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html and since IIUC that's not an issue any more.... John now if I could only figure out why my mail client seems to be dropping any patches with "crypto" in the subject line (I'm missing patches 2-4 and 10 from the series referenced above)...
Martin Kletzander
2018-May-30 20:21 UTC
Re: [libvirt-users] [libvirt] virRandomBits - not very random
On Tue, May 29, 2018 at 10:06:25AM -0400, John Ferlan wrote:> > >On 05/29/2018 09:44 AM, Michal Privoznik wrote: >> 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 >> > >I have this faint recollection of one of the CI platform builds failing >because something in the gnutls* family didn't exist there when I was >making the changes to add the domain master secret code.... After a bit >of digging, it seems it was a perhaps a CENTOS6 environment: > > https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html > >and since IIUC that's not an issue any more.... >Oh, cool to know. Michal also found the patch [1] where Dan switched the gnutls from being mandatory to making it optional and there is no explanation for that change in the commit message: [1] f587c27768ee13f5bed6a9262106307b7a124403>John > >now if I could only figure out why my mail client seems to be dropping >any patches with "crypto" in the subject line (I'm missing patches 2-4 >and 10 from the series referenced above)...Maybe you have some weird server-side filter for it?