[Cryptography] randomness +- entropy

[Theodore Ts'o]

On Tue, Nov 05, 2013 at 05:31:12PM -0500, John Kelsey wrote:
> 
> Is there any way for a program to find out if /dev/urandom has been
> seeded properly?

Currently, there isn't.  We could add it, but most programs aren't
going to check for such a flag.  So one of the things which I've
recently added: 

    http://git.kernel.org/cgit/linux/kernel/git/tytso/random.git/log/?h=dev

are changes so that when the pool is initialized, you get a kernel
printk in dmesg:

random: nonblocking pool is initialized

Also, if a process tries to access /dev/urandom before it's
initialized we do this:

		printk_once(KERN_NOTICE "random: %s urandom read "
			    "with %d bits of entropy available\n",
			    current->comm, nonblocking_pool.entropy_total);

Which will result in something like:

random: ssh-keygen: urandom read with 52 bits of entropy available


My current thinking is that whether or not urandom is fully
initialized by the time should really be more of an attribute of the
overall system design rather than the application program.  Hence my
emphasis on having kernel printk's so we can understand whether or not
we have a problem, and if so, how bad is it.  My expectation is that
we're probably fine for most x86 desktops and servers (so most
developers who use those as development machines don't have a strong
incentive to do much on those platforms), but we have a much bigger
problem on ARM and MIPS embedded/consumer electronics devices.

I could add an ioctl which returns the state of the pool initialized
flag, or which blocked until the pool is considered initialized, but
I'm not convinced that enough programs would really use it.  And if I
made /dev/urandom reads block until the pool was initialized, I
suspect that product managers would just tell the engineers to patch
out the check, as opposed to doing something intelligent, such as
demanding that ARM vendors including a HWRNG in their SOC, or at least
include a CPU cycle counter register --- since that might increase the
BOM cost by a few pennies, and that would be considered unacceptable.
(You think I'm kidding --- I recently learned that hard drive
manufacturers measure cost in millicents.  Think about that, and
shudder....)

Still, I suppose it wouldn't hurt to add such an ioctl interface, even
if it never, or rarely, gets used.

					- Ted