On Friday 15 April 2016 17:51:36 H. Peter Anvin wrote: > On April 15, 2016 9:10:44 AM PDT, Hubert Kario <hkario@xxxxxxxxxx> wrote: > >On Friday 15 April 2016 09:47:51 Eric Blake wrote: > >> On 04/15/2016 04:41 AM, Cole Robinson wrote: > >> > Libvirt currently rejects using host /dev/urandom as an input > > > >source > > > >> > for a virtio-rng device. The only accepted sources are > >> > /dev/random > >> > and /dev/hwrng. This is the result of discussions on qemu-devel > >> > around when the feature was first added (2013). Examples: > >> > > >> > http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02387.htm > >> > l > > > >https://lists.gnu.org/archive/html/qemu-devel/2013-03/threads.html#0 > > > >> > 0023 > >> > > >> > libvirt's rejection of /dev/urandom has generated some complaints > >> > from users: > >> > > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1074464 > >> > * cited: http://www.2uo.de/myths-about-urandom/ > >> > http://www.redhat.com/archives/libvir-list/2016-March/msg01062.ht > >> > ml > >> > http://www.redhat.com/archives/libvir-list/2016-April/msg00186.ht > >> > ml > >> > > >> > I think it's worth having another discussion about this, at least > >> > with a recent argument in one place so we can put it to bed. I'm > >> > CCing a bunch of people. I think the questions are: > >> > > >> > 1) is the original recommendation to never use > >> > virtio-rng+/dev/urandom correct? > >> > >> That I'm not sure about - and the answer may be context-dependent > > > >(for > > > >> example a FIPS user may care more than an ordinary user) > > > >/dev/urandom use is FIPS compliant, no FIPS-validated protocol or > >cryptographic primitive requires the "fresh" entropy provided by > >/dev/random. All primitives are designed to work with weaker entropy > >guarantees than what /dev/urandom provides. > > So: using urandom for a seed makes sense, but "unplugging the drain" > is a huge waste of resources and provides absolutely zero value. Since when "wasting resources" is worse than performing Denial of Service on your own infrastructure? Besides, what's the difference between spinning a CSPRNG in host rather that guest? If anything, spinning CSPRNG in host is less of a waste as the virtualisation overhead (however small) isn't there. If you need X number of random bytes, you need to provide X number of random bytes. The software simply won't work otherwise. > Also, I do not believe /dev/urandom is FIPS compliant. Finally, the > refill policy is different, so it is not really true the algorithm is > the same. We did discuss it with NIST, have you? The refill policy doesn't matter, after the pool is seeded, it will continue generating unpredictable random numbers for years (if not decades or centuries) without any additional entropy. And you certainly will gather enough entropy to reseed /dev/urandom multiple times an hour, even if the host does not do anything but generate random numbers. > All in all, other than a seed value it really doesn't make any sense. > Of course, none of this matters on newer Intel hardware ;) Not everybody is running on newer Intel, not everybody is even running on x86_64 architecture. Not everybody trusts the RNG in Intel hardware (e.g. rdrand is a not-Approved algorithm for FIPS certified software). -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list