[Cryptography] [RNG] /dev/random initialisation

Stephan Mueller smueller at chronox.de
Mon Oct 28 12:41:44 EDT 2013


Am Montag, 28. Oktober 2013, 12:35:29 schrieb Sandy Harris:

Hi Sandy,

>Stephan Mueller <smueller at chronox.de> wrote:
>>> 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.
>
>Only an attacker who can log into the system. That blocks
>most remote attackers, and something like a router (the
>sort of system where this is most likely to be an issue)
>should have tightly restricted logins.

You are right, I only considered scenarios where adversaries can log on. 
In your considered situation, I concur that the information does indeed 
add entropy.
>
>> Thus, the information has zero entropy and can
>> only be used to stir the pool more.
>
>Sure, and I definitely am not saying either that this sort of
>thing should be given entropy credit or that you don't need
>better sources as well. My only question is whether this is
>useful as a worst case fallback measure.

Right. Also see the answer from the Debian developer on LKML today who 
says that on Debian the kernel log or similar is injected into 
/dev/random.
>
>> If you stir in the time stamp when
>> you invoke the commands, you may get entropy from that time stamp.
>
>Yes, and uname -a includes a timestamp.

Right. But I meant the time stamp as follows:

ifconfig > /dev/random
clock_gettime(CLOCK_REALTIME) > /dev/random
netstat > /dev/random
clock_gettime(CLOCK_REALTIME) > /dev/random
...

>
>> 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.
>
>This looks to be a real problem, or at least a restriction on
>which things can be used there. Perhaps Ted can comment?
>
>User space programs can inject data at any time, but it may
>come too late if the driver produces output early and it may
>be quite unnecessary once other entropy sources have made
>some contributions. The stuff I suggest above is certainly
>possible, but it may not actually be useful, let alone needed.

I fully concur.

Ciao
Stephan


More information about the cryptography mailing list