Re: [libvirt] RFC: virtio-rng and /dev/urandom
On Friday 15 April 2016 17:51:36 H. Peter Anvin wrote:
On April 15, 2016 9:10:44 AM PDT, Hubert Kario
<hkario(a)redhat.com>
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
Attachments:
- signature.asc (application/pgp-signature — 819 bytes)