[Cryptography] OpenSSL and random

[Theodore Ts'o]

On Wed, Nov 30, 2016 at 10:23:06AM -0800, Ray Dillinger wrote:
> For those who don't chase email links ever, or who do but didn't
> recognize the above host so refrained, the short version of the story is
> that getrandom() blocks unless sufficient initial entropy has been
> collected, but is nonblocking forever after.  Which is, IMO, the right
> thing.  I would happily alias urandom to this, but as TT pointed out in
> the checkin, changing the behavior of urandom could break userspace
> programs.

More than that, the 0 day kernel test system (many thanks to Intel)
verified that such a kernel change (to cause /dev/urandom to block
until there was enough entropy) would break at least one fairly modern
Ubuntu setup as well as OpenWRT.  What OpenWRT was trying to do to
read from /dev/urandom that early in the boot sequence was something I
never bothered to figure out, since I use Google onTAP for my routers
these days, and I've been too busy.  Someone who does use OpenWRT
might want to take a look, though.

If you are using a systemd system that uses Python scripts to generate
systemd config files dynamically at boot time from //etc/fstab,
et. al, if you are using the wrong version of Python (newer versions
use getrandom0, making /dev/urandom block until there is enough
entropy will brick your System/VM.

(In case people had been wondering why I didn't just make this change
years ago, despite lots of ranting and raving on lists like this, it's
because I *worry* about things like this.)

						- Ted

P.S.  Silly bit of trivia: the reason why Python was reading fom
/dev/urandom was to initialize a hash directory to prevent DOS attacks
when Python was being used from a CGI script.  Not an issue when it is
being used as a system generator, but....  and that's why you
shouldn't panic when there are reports that system'd udev and Openwrt
are reading from /dev/urandom during early boot.  In some cases, it's
for completely innocuous things. Like lint warnings, though, it's good
to check them and if possible silence them so when someone is creating
long-term public keys immediately after a device is first powered up,
people are more likely to notice...