On Po, 2014-04-28 at 15:22 +0200, Florian Weimer wrote:
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>
OK, that's better.
>> 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.
Yes, but having indicative /proc value shouldn't really harm.
--
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.)