Re: [libvirt] virRandomBits - not very random

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Attachment: signature.asc
Description: Digital signature

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux