[Cryptography] RFC possible changes for Linux random device

[Sandy Harris]

On Mon, Sep 15, 2014 at 3:20 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> 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.

I've suggested something similar in a comment in loop_urandom(),
done once for each /dev/urandom read.

    Mix in process info for reading process
    apply addmul() to task_info struct

    This depends on a different aspect of the
    system than anything else in the driver,
    namely the order in which user processes
    ask for data and the current state of those
    processes.

I am not sure if the task_info struct changes enough that this
would accomplish the goal or if you'd need a per-task key as
you suggest. If you do need the key, this would be the place
to add it.

I have the code for addmul(), the mixer from AES-GCM, but
not the actual code that would apply it here.