[147865] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] /dev/random initialisation
daemon@ATHENA.MIT.EDU (Sandy Harris)
Mon Oct 28 13:42:31 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <2731260.dQAiBoVfXi@tauon>
Date: Mon, 28 Oct 2013 12:35:29 -0400
From: Sandy Harris <sandyinchina@gmail.com>
To: Stephan Mueller <smueller@chronox.de>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Stephan Mueller <smueller@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.
> 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.
> 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.
> 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.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
