[libvirt] [libvirt-users] virRandomBits - not very random

[Michal Privoznik]

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