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.)
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
