[Cryptography] RFC possible changes for Linux random device

Jason Cooper cryptography at lakedaemon.net
Sat Sep 13 15:08:36 EDT 2014


Sandy,

+ Ted Ts'o, H. Peter Anvin

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.

This is easy to say, but difficult to confirm.  ;-) See my trailing
instructions.

> It uses the 128-bit hash from AES-GCM instead of 160-bit SHA-1.

This has been discussed before, and I don't believe anyone is directly
opposed to it.

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

Ok.

Here's my recommendation:  Follow the instructions below to generate a
patch against the current, mainline kernel tree.  Then post the patch to
lkml with Ted Ts'o, and H. Peter Anvin on the Cc.

We need to see a diff against the mainline tree because it allows us to
more easily review your idea(s).

Before submitting, there are a few quick and easy things you can clean
up before submitting the first version.  You could review
./Documentation/SubmittingPatches, or just run ./scripts/checkpatch.pl on
your patch.  I wouldn't worry about removing _all_ warnings, just clean
up all the big ones.  At any rate, give this a whirl:

*If you already know git, then this is just a post for posterity  ;-)

--- Begin ---

# pull down a copy of Linus' tree
$ cd
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux

# tell git who the developer is
$ git config --add user.name "Sandy Harris"
$ git config --add user.email "preferred_email_in_git_history"

# create a branch for your changes, based on a mainline tag
$ git checkout -b random_aes128 v3.17-rc1

# copy your code in
$ cp .../path/to/random.c ./drivers/char/random.c

# take a look at the diff, are there
#  - unnecessary whitespace changes?
#  - needless renamings?
#  - unnecessary function re-ordering?
$ git diff

# cleanup as necessary
$ $EDITOR drivers/char/random.c

# run checkpatch
$ git diff | ./scripts/checkpatch.pl -

# build test
$ make defconfig
$ make -j9 -q bzImage

# repeat the last three steps until the errors are gone and the
# checkpatch warnings are few / debatable (remember, it's a tool, not a
# human)

# commit the result
#   NOTE: '-s' adds the 'Signed-off-by: Name <email>' to the commit
#   Please read the Developer's Certificate of Origin:
#     http://developercertificate.org/
#   And *only* add '-s' if you agree to the DCoO.
$ git commit -a -s

# in the editor

E> random: Convert to aes128-gcm for mixing.
E>
E> <paragraph or two discussing what problem you encountered, how this
E>  patch solves it, and include any relevant metrics validating the
E>  claim>
E>
E> Signed-off-by: Sandy Harris <email_address>

# create a patch file
$ git format-patch --no-thread --no-cover-letter -N v3.17-rc1..random_aes128

# And send it
$ git send-email --to="Theodore Ts\'o <tytso at mit.edu>" \
	--to="H. Peter Anvin <hpa at zytor.com>" \
	--to="Jason Cooper <jason at lakedaemon.net>" \
	--cc="linux-kernel at vger.kernel.org" \
	$SMTP_OPTS 00*.patch

Please look at 'git send-email --help' for the smtp options you'll need.

--- End ---

I wrote this from memory, so there's probably a typo or three. :)  If
you get stuck, shoot me an email and I'll be happy to assist.

A fair head's up:  You're going to get a lot of warnings on comment
style.  Single-line comments are '/* ... */' and multi-line are:

	/*
	 * something
	 * about the code goes here
	 */

Yes, there are many ways to do it, but I always try to conform to the
style of a given project so it's consistent within that tree.

thx,

Jason.


More information about the cryptography mailing list