On 04/28/2014 03:05 PM, Tomas Mraz wrote:
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.
The idea is that a blocking generator such as /dev/random should be
secure even against a full cryptanalysis of the pool mixing primitives.
I don't know if the Linux /dev/random design hits this goal.
I agree that this is *probably* not practically relevant, but I don't
want to cover this particular debate in the guidelines.
What about this version? Do you think it's sufficiently balanced?
<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>. This can result in
weak keys if the system lacks a proper entropy source (e.g., a
virtual machine with solid state storage). Depending on local
policies, keys generated by these OpenSSL tools should not be
used in high-value, critical functions.
</para>
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?
Hmm, that could make sense.
On the other hand, blocking until entropy is available could result in
preventing system startup because nothing is running that would trigger
entropy production.
--
Florian Weimer / Red Hat Product Security Team
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
