[Cryptography] RFC possible changes for Linux random device

Theodore Ts'o tytso at mit.edu
Mon Sep 15 23:31:03 EDT 2014


On Mon, Sep 15, 2014 at 05:19:07PM -0400, Sandy Harris wrote:
> 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....

What I have in mind is much simpler.  The executive summary:

When a process tries to open /dev/urandom or tries to use the new
getrandom(2) system call for the first time, if the AES cipher is
enabled, grab a key and use it set up crypt_tfm structure which would
be hanging off the Linux's current (task_struct) struxture, using the
ctr(aes) cipher.  If this is successful, in order to generate N bytes
of randomness, encrypt using ctr(aes) a buffer filled with RDRAND (if
available) or all zero's (if not).

If the aes ctr crypto_blkcipher couldn't be set up, either because of
some kind of failure (most commonly ENOMEM), or because the AES cipher
is not enabled, fall back to using the existing urandom pool.

On a process, exit, exec, or fork, crypto_free_blkcipher(current->tfm)
gets called to zap the crypto context.

This has a couple of advantages.

(1) it will be much easier to audit than your thousands of lines of
changes.

(2) we can guarantee that it will be no worse than what we currently
have, if in the worst case we fall back to old scheme.

(3) we can take advantage of all of the hardware acceleration of AES
(i.e., using AESNI for x86, etc.) wihtout having to drag a huge amount
of complexity into drivers/char/random.c.

Cheers,

					- Ted


More information about the cryptography mailing list