[Cryptography] RFC possible changes for Linux random device

[Jason Cooper]

On Sat, Sep 13, 2014 at 03:22:07PM -0700, John Denker wrote:
> On 09/13/2014 08:59 AM, Jonathan Thornburg asked about:
> 
> > 1) be faster?
> > 2) to be stronger against cryptographic analysis of its output?
> > 3) provide high-quality randomness earlier in the boot sequence?
> > 4) use less kernel memory?
> > 5) be more resistant to cache or timing attacks by malicious user code
> >   running the local processor?
> > 6) more resistant to cache or power-consumption side-channel attacks
> >   mounted by an attacker with physical (but not software) access to
> >   the local processor & memory?
> > 7) be more resistant to timing attacks by attackers on the local network?
...
> I agree with Sandy that item (3) is "critically important".
> It should be moved up the priority list.  It's doable, but
> not easy.  About 100 wrong ways of doing it have been
> suggested, in this forum and elsewhere.

Here's the 101st:

  - have existing /etc/init.d/urandom scripts also dd 512 bytes into
    /boot/random-seed

  - on boot, bootloader reads /boot/random-seed into memory and hands
    the address/size to the kernel.

  - optionally, if the user trusts the SoCs hwrng, the bootloader could
    read 512 bytes from it into memory instead.  Or, mix it with
    random-seed.

The kernel decompressor can use some for initializing KASLR, and the
rest can be used when the entropy pools are initialized.

This doesn't solve the problem of first-boot, which is unfortunately
when some long-term keys are generated.  It does facilitate solving the
problem, though.  System implementers who care can provision the
random-seed from an established entropy source at the same time they
provision the board mac addresses (I'm referring to embedded systems
which store their mac addresses in the bootloader's environment)

thx,

Jason.