libvirt users - May 2018 - Re: [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

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)...

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?