[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