---------- Forwarded message ---------- From: coderman <coderman@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@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* ]