[Cryptography] RFC possible changes for Linux random device

[Theodore Ts'o]

On Fri, Sep 12, 2014 at 07:18:58PM -0400, Sandy Harris wrote:
> I have some experimental code to replace parts of random.c It is not
> finished but far enough along to seek comment. It does compile with
> either gcc or clang, run and produce reasonable-looking results but is
> not well-tested. splint(1) complains about parts of it, but do not
> think it is indicating any real problems.
> 
> Next two posts will be the main code and a support program it uses.
> 
> I change nothing on the input side; the entropy collection and
> estimation parts of existing code are untouched. The hashing and
> output routines, though, are completely replaced, and much of the
> initialisation code is modified.
> 
> It uses the 128-bit hash from AES-GCM instead of 160-bit SHA-1.
> Changing the hash allows other changes. One design goal was improved
> decoupling so that heavy use of /dev/urandom does not deplete the
> entropy pool for /dev/random. Another was simpler mixing in of
> additional data in various places.

Something to think about in terms of doing this as a very simple
change.  I've considered for a while the thought of using a
per-process key, lazily generated the first time a process tries to
read from /dev/urandom, and which hangs off the task struct, and which
gets released on task exit or on an exec, and which is *not* inherited
across a fork.

That way, there's absolutely no question that a heavy entropy user
from one process would influence the random number stream that would
be made available to another process.

We can keep the urandom pool for now for kernel-calls to
get_random_bytes.  In fact, it might be used to generate the keys for
the per-process entropy state.  In the future, we can potentially
change this to use something else; but this would be very simple to
reason about, and it's in fact what I think all users of /dev/urandom
should do in userspace, except for the problem of what happens in a
library when the application forks.

					- Ted