[Secure Coding] master: sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue (564ffc8)

[Pavel Kankovsky]

On Mon, 28 Apr 2014, Florian Weimer wrote:

> On 04/28/2014 03:05 PM, Tomas Mraz wrote:
>>  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 idea is that a blocking generator such as /dev/random should be secure 
> even against a full cryptanalysis of the pool mixing primitives.

Strictly speaking, the pool mixing primitives (twisted GFRS) would be easy 
to break were they not protected by the hash function (SHA-1) used to 
transform bits in a pool into output.

IMHO, /dev/random is supposed to return "fresh" bits of entropy and even 
an advesary with access to unlimited computing power and an unlimited 
supply of observed bits acquired from /dev/random (or urandom) should be 
unable to guess anything about output that has not been observed.

On the other hand, /dev/urandom "recycles" entropy (until it is reseeded). 
A very powerful adversary who observes enough bits of output might be able 
to reconstruct its internal state and recompute unknown output.

This is a substantial theoretical difference.

>  I don't know if the Linux /dev/random design hits this goal.

Good question. I am inclined to say "probably no" because it seems to me 
it depends on the properties of SHA-1 and SHA-1 is far from perfect. But 
do not quote me, I am not a cryptologist.

-- 
Pavel Kankovsky aka Peak                      "Que sais-je?"