On Po, 2014-04-28 at 14:55 +0200, Florian Weimer wrote:
> On 04/28/2014 02:36 PM, Tomas Mraz wrote:
>
> >> diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml
> >> index 936910d..f4da007 100644
> >> --- a/defensive-coding/en-US/Features-TLS.xml
> >> +++ b/defensive-coding/en-US/Features-TLS.xml
> >> @@ -186,6 +186,15 @@
> >> verify</command> result in an exit status of zero.
> >> </para>
> >> <para>
> >> + OpenSSL command-line commands, such as <command>openssl
> >> + genrsa</command>, do not ensure that physical entropy is used
> >> + for key generation—they obtain entropy from
> >> + <filename>/dev/urandom</filename> and other sources, but not
> >> + from <filename>/dev/random</filename>. Keys generated by
> >> + these tools should not be used in high-value, critical
> >> + functions.
> >> + </para>
> >
> > This one is quite questionable. We should not make impression
> > that /dev/urandom is insecure apart from situations where the kernel is
> > not seeded with entropy.
>
> I tried to word in a way that doesn't give the impression that
> /dev/urandom is insecure, while still pleasing those who strongly think
> that long-term key material should be generated from /dev/random.
The fact is that once the kernel entropy pool is properly seeded the
theoretical properties of the random numbers outputted from /dev/random
and /dev/urandom do not differ that much. The only difference is in case
where the attacker could snapshot the kernel entropy pool contents and
no sufficient reseed could happen before the key was generated. However
in this case using /dev/random would just mean that the system would
wait for additional entropy giving the attacker the possibility to
obtain additional snapshot.
> > Of course in case of diskless machines the
> > entropy seeding of the kernel entropy pool might be very scarce and just
> > after boot the entropy in the pool might be insufficient. But once the
> > kernel pool is properly seeded once the generated pseudorandom numbers
> > are secure. I would say that keys for high-value, critical functions
> > (but how are these really defined) should not be generated on virtual
> > machines or diskless routers or similar machines where the entropy
> > sources are limited.
>
> Is there a way to check in /proc that the kernel has initialized the
> pool? I know the kernel prints a message. A low value in
> /proc/sys/kernel/random/entropy_avail does not necessarily mean that no
> entropy was mixed into the pool.
Unfortunately I do not know of such way. Perhaps this should be added as
additional /proc value?
> Is it possible to express that a seeded /dev/urandom is needed as a
> systemd dependency?
Given the above it is probably not possible. However Fedora init process
currently reseeds entropy pool with data saved from previous boot cycle
before shutdown.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
