Fwd: Debian System and /dev/random

[coderman]

---------- Forwarded message ----------
From: coderman <coderman at gmail.com>
Date: Sun, Jan 19, 2014 at 4:57 PM
Subject: Re: Debian System and /dev/random


On Sun, Jan 19, 2014 at 11:41 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> I'm working on a laptop with quad core i5 running Debian 7.3 x64
> (fully patched).
>
> You know this damn thing was running out of entropy in /dev/random
> because no entropy daemon was installed out of the box....


since 2004 building my own rngd, my own FDE bootloader, my own
mandatory entropy health watchdog service, in every distribution: none
did FDE key management right (for loop-aes at the time), none did
entropy right.


in 2008 various "expert install" console only options began to support
a suitable FDE solution with luks and boot by volume GUID (rather than
device file).

many years we've had full blown easy (for some degree of easy) FDE
solutions in graphical installers out of the gate. progress!


and yet entropy, the most critical component of any crypto system, is
so horribly and woefully inadequate today. will no indications this
will change soon...

this is not an accident.  :/



> And I was depleting it with a simple program that tried to read 32
> bytes to seed an OpenSSL generator. I could only get 9 or 16 or 19
> bytes out of it

yup.  for fun, check out how this setup seeds itself:

https://github.com/catid/cymric/
"""
Linux/Android:

/dev/random (160 bits)
/dev/urandom (96 bits)
srand() and rand() from stdlib (64 bits)
gettid() or pthread_self() (32 bits)
getpid() (32 bits)

Linux-type systems are a little strange in that /dev/random only keeps
about 20 bytes of entropy in reserve. And it takes roughly 20 seconds
for a VPS to collect 8 bytes of entropy, which means asking for 32
bytes of entropy takes an unreasonably long time. By asking for only
20 bytes, most of the requests by this library will complete
immediately. And the remaining 12 bytes are satisfied by
/dev/urandom...
"""



> Seriously... That's all it was on startup....
>
> That's amazing in 2013........


amazingly effective!  BULLRUN FTW

[EDIT: to clarify, i am lamenting the lack of high rate, raw source
physical entropy sources as native instructions in processors.  this
should be a baseline mandatory requirement!  i am also lamenting the
lack of user space entropy daemons and collectors being enabled by
default in most distributions.  i am also lamenting the lack of proper
boot time / VM pass through entropy support in most distributions.  i
am lamenting the lack of any failure handling for entropy in any
distribution, such that a failed RNG condition leads to service halt
rather than blindly carrying on, perhaps for years, unaware that
you're broken. i am also lamenting the lack of serious attention and
thoroughness applied to entropy sources in nearly every computing
system deployed across this planet.  i could go on, but you get the
point... *grin* ]