[147707] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Kent Borg)
Thu Oct 17 13:07:02 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 17 Oct 2013 13:05:52 -0400
From: Kent Borg <kentborg@borg.org>
To: cryptography@metzdowd.com, tytso@mit.edu
In-Reply-To: <20131017123257.GA23361@netbook.cypherspace.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 10/17/2013 08:32 AM, Adam Back wrote:
> I think the more worrying case is a freshly imaged rack mount server,
> immediately generating keys or outputting random numbers to the
> network or
> in response to network queries.
There are certainly larger system issues, and anyone doing
auto-provisioning of servers and generating keys before any entropy has
accumulated could get burned. Though to be fair to /dev/random, isn't
this a larger Linux distribution issue? Don't automatically generate
keys on first boot. RNGs that need seed data should not be run empty.
But is this something that /dev/urandom might do better? Should
blocking be added to /dev/urandom immediately after boot until some
reasonable threshold has been reached at least once? Or on first boot
are common distributions restoring a bad seed file and /dev/random can't
tell? Arrgh, I am starting to think that the RNG is the wrong place to
fix it.
Should RNGs attempt to detect uninitialized states and refuse to run?
-kb
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
