[Cryptography] /dev/random is not robust

Theodore Ts'o tytso at mit.edu
Thu Oct 17 17:07:10 EDT 2013


On Thu, Oct 17, 2013 at 01:05:52PM -0400, Kent Borg wrote:
> 
> 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.

The major problem which could be considered a "Linux distribution
issue" is ssh host key generation, which is done by the boot scripts
if the ssh host keys do not exist.  It would be much better if this
was done on the first TCP connection to the ssh server, but that would
require changes to sshd.

The other places where there are problems will be creation of
public/private key pairs when a printer first boots up, but that's not
really "Linux distribution code".  

> 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?  

I have seriously been thinking about adding that.  The main thing
which is causing me pause is I need to make sure that on low entropy
devices, that we don't end up stalling processes which require
/dev/urandom access for too long.  One could argue that those devices
were broken already, but it might be our fault because we're using too
conservative of an entropy estimate.  The issue is if it becomes too
onerous, people will just simply "fix" the kernel regression by
commenting out the check, and then it will be harder for me to get
that functionality re-added in the future.

So there's some measurements that need to be done before I'd be
comfortable turning this on, at least as the default.  What I might do
is to add some tuning parameters that could be passed on the kernel
boot command-line which forces /dev/urandom accesses to block until N
bits of entropy have been accumulated or M seconds, whichever comes
first, and we would log a kernel message as soon as /dev/urandom is
considered initialized.  It least initially, N would probably be
defaulted to zero, which would disable this feature, and M would be
300 seconds or some such.  Users could then experiment on various
different devices before we made a final decision about whether this
feature should be enabled by default.

> Or on first
> boot are common distributions restoring a bad seed file and
> /dev/random can't tell?

When the init scripts restore the seed file, there is no entropy
credits given.  So if the seed file has been compromised, it's not a
disaster because we don't assume the seed file is guaranteed to have
any entropy.  OTOH, if the seed file is good, then we'll obviously be
much more secure.

						- Ted


More information about the cryptography mailing list