[Cryptography] randomness +- entropy

[Watson Ladd]

On Tue, Nov 5, 2013 at 3:09 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> 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.
Nothing outside the kernel can determine if entropy has been added to
the kernel pool.
Furthermore, plenty of programs like gpg and openSSH would use it, and those
are the important ones where lack of randomness can hurt very badly.
>
> 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....)
And in the current situation the engineers and product managers have
no idea if the kernel
is collecting enough entropy.
Furthermore, the cost of adding a cycle counter on chip is much less
than of things that are selling points: built-in crypto
acceleration, etc.
>
> Still, I suppose it wouldn't hurt to add such an ioctl interface, even
> if it never, or rarely, gets used.
>
>                                         - Ted