[Cryptography] [RNG] /dev/random initialisation

[Stephan Mueller]

Hi Sandy,

Thank you for summarizing that issue.

...
> 
> There are two ways one might get suitable material into the driver
> state. One can build it into the kernel's device initialisation code
> 
> or do it externally with a script along the lines of:
>     ifconfig > /dev/random
>     netstat > /dev/random
>     uname -a > /dev/random
>     ....

I do not think that this is helpful as any attacker is able to obtain 
such information as well. Thus, the information has zero entropy and can 
only be used to stir the pool more. If you stir in the time stamp when 
you invoke the commands, you may get entropy from that time stamp.

Furthermore, random.c is initialized so early in the boot cycle that 
neither the kernel nor user space has any ability to inject meaningful 
data to mix the initial state.

...

> It looks as though getting 64 bits or more is possible. One of the
> FreeBSD guys wrote on the other crypto list:
> http://lists.randombit.net/pipermail/cryptography/2013-October/005689.
> html

I would like to see the measurement they reference. However, I expect 
that 4 bits or more are based on the timer resolution being so high that 
no attacker can determine the precise device attachment time with a 
precision of more than 4 bits (e.g. 2**4 ns).

If we have such a high resolution timer, the CPU Jitter RNG will work as 
well. Thus, I took your suggestion and updated the CPU Jitter RNG patch 
to stir the entropy pools of random.c when they are initialized in 
init_std_data().

My tests show that the jitter is all present at that time and can well 
be used to stir the pool. Please see 
http://www.chronox.de/jent/jitterentropy-20131028.tar.bz2, file 
patches/linux-3.11-random.patch.

That patch is such that at the time of init_std_data, 32 bytes (i.e. 256 
bits) of entropy from the jitter is added to the entropy pool which is 
enough to already generate keys with sufficient strength.


Ciao
Stephan