essary complex, which means it is more likely to have bugs in
it
besides, it's still feeding CSPRNG output to CSPRNG, no matter if it
reads the bits from /dev/random or /dev/urandom
kernel will not provide you with raw random values it gathered
so again, why block users from setting the ran
e
output unpredictable and unique between multiple machines starting from
the same snapshot, feeding enough random data to make the entropy pool
unique again is sufficient to achieve that
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Cz
On Friday 15 April 2016 17:51:36 H. Peter Anvin wrote:
> On April 15, 2016 9:10:44 AM PDT, Hubert Kario
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
ompliant, 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.
--
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
signature.asc
Description: This is a digitally signed message part.
gt; >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 ar
