[Cryptography] RNG design principles

[John Denker]

On 11/27/2016 09:55 AM, Ard Biesheuvel wrote:

> I think using a separate file altogether is a better idea.

Yes.  I'm convinced.  That's better in terms of security
and compatibility.

This means we need two versions of the command:  one to
read the file, and another to accept input interactively
from the user.  This should be easy enough.


> [...] presumes knowledge of/access to the real time clock.

Grub itself does not need such access.  Instead it can rely
on the kernel to mix in the RTC, along with the random seed,
before the first use of the RNG.

  This may impose some requirements on the kernel configuration,
  perhaps specifying "y" (for built-in driver) rather than "m"
  (for loadable module) when configuring the RTC ... but that's
  a price I'm willing to impose.


> If the boot firmware is UEFI, it knows about configuration tables. If
> it doesn't, then there is no point in using this mechanism: we cannot
> impersonate a UEFI system.

We agree we shouldn't pretend it's something it's not ... but
still I'm not ready to write off the entire non-UEFI segment of
the population.  In cases where we can't use the UEFI mechanism,
perhaps we can use an /analogous/ mechanism, just so long as it
lets us pass a high-quality seed to the kernel.  I haven't looked
at the code, but I reckon passing a not-quite-UEFI block can't
be too much harder than passing an actual-UEFI block.


On 11/27/2016 10:29 AM, Theodore Ts'o wrote:
>> you might as well pass it as a binary extension to
>> the boot-time protocol, which is how the boot loader passes the
>> command line and initrd information to the kernel.  For an example of
>> the x86 boot command loader, please see:
>> 
>> 	https://www.kernel.org/doc/Documentation/x86/boot.txt 

Yes.


>> This doesn't completely solve the "out of the box problem", of course

Those who put the system "into the box" simply MUST bestow some
randomness on it.  Once the aforementioned mechanism is in place,
we must insist that manufacturers and packagers use it.


>> The bottom line is that the
>> step requires changes in a multiple components --- in the kernel, the
>> boot loaders, the distribution installers, etc. etc.

We agree, it's a multi-piece puzzle.  But I'm quite optimistic.
Some very large pieces are starting to fall into place.