[Cryptography] RFC possible changes for Linux random device

[John Denker]

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?

Those are all noble goals.

Note that I've never been able to get a straight answer
about the goals or requirements for the legacy "standard"
random.c, so to the extent that Sandy can address /any/
of the listed items, that's valuable progress.

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.

Other items such as (2) are equally critical, but more
straightforward to accomplish.

I would suggest one more high-priority item for the list:

8) be more frugal with the available real entropy, in
 situations where entropy input is limited yet a large
 amount of PSEUDOrandom output is required.

 Such situations are critical, and not particularly rare.

==========

In the spirit of covering all the bases, I would like
to mention but /not/ advocate one further item:

x) rapidly recover from compromise of the PRNG internal
 state.

For years, the legacy "standard" random.c has been
obsessed with this goal, out of proportion to its
actual practical importance, to the great detriment 
of other goals including item (8).