[Top][All Lists]

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

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

From: Hubert Kario
Subject: Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom
Date: Fri, 15 Apr 2016 18:06:17 +0200
User-agent: KMail/4.14.10 (Linux/4.4.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; )

On Friday 15 April 2016 08:56:59 H. Peter Anvin wrote:
> On April 15, 2016 3:41:34 AM PDT, Cole Robinson <address@hidden> 
> >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.html
> >https://lists.gnu.org/archive/html/qemu-devel/2013-03/threads.html#00
> >023
> >
> >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.html
> >http://www.redhat.com/archives/libvir-list/2016-April/msg00186.html
> >
> >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?
> >
> >2) regardless of #1, should we continue to reject that config in
> >libvirt?
> >
> >Thanks,
> >Cole
> Using /dev/urandom for virtio-rng, *except* perhaps for a small seed,
> it a complete waste of cycles.  There is absolutely no reason to have
> one prng feed another.

/dev/random is a prng too, both /dev/random and /dev/urandom use exact 
same algorithm

and yes, there are multiple reason for feeding one prng with another, 
all cryptographic protocols do that all the time (e.g. TLS Pseudo-Random 
Function output is fed as key to AES-GCM, both PRF and AES-GCM are 
essentially PRNGs)
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]