public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: random(4) driver questions
Date: Tue, 28 Jun 2011 10:42:06 -0400	[thread overview]
Message-ID: <20110628144206.GJ2729@thunk.org> (raw)
In-Reply-To: <BANLkTin1cABBLn0yPxk6oyTbw4miN7TEPw@mail.gmail.com>

On Tue, Jun 28, 2011 at 02:02:58PM +0800, Sandy Harris wrote:
> However, for the secondary pools, a block cipher seems to
> me to be the obvious thing to use because there is plenty
> of analysis, in the Yarrow paper and follow-ups, of that
> technique. Also, I think it might be faster.

Well, there hasn't actually been any analysis of the use of a block
cipher.  The Yarrow paper and all follow-ons that I'm aware simply
assume that the block cipher is secure.  Most of the Yarrow analysis
has been on what I consider to be largely pointless, academic
considerations about "what if you're able to get the internal state".
(Whereas I'm of the opinion, if you can get access to the internal
state of the kernel, you probably can do a lot of other things that
are much bigger deal --- such as, dropping in a root exploit and then
start tapping your keyboard, network, etc.)

> An AES-128 context, 11 128-bit round keys, is roughly the
> same size as one of the current secondary pools, 32 32-bit
> chunks. What would maintainers think of a patch along
> those lines?

But if you're ditching the AES key scheduling step, it's no longer
AES, which means all of the analysis for AES not necessarily
applicable....  So if you're going for a cryptographic conservative
design, it's not at all clear to me that a bastardized AES is an
improvement.

Also, note that faster is *not* a feature for a random number
generator...

> Another question is whether and when we might replace
> SHA-1 with a more modern hash. Jeff Garzik has a patch
> to add Skein to the crypto API. That would be faster
> than SHA-1 and perhaps more easily analyzed since
> the compression function is a block cipher. Of course
> the SHA-3 Advanced Hash Standard process is not
> scheduled to finish for another year and there's a
> good argument that we should wait for that.

Waiting for SHA-3 (and then giving a bit more time for the
cryptographers to spend more time trying to attack it) seems like a
better approach to me....

						- Ted

      reply	other threads:[~2011-06-28 14:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-25  5:51 random(4) driver questions Sandy Harris
2011-06-25 12:53 ` Alexander Clouter
2011-06-27 14:54 ` Ted Ts'o
2011-06-27 15:08   ` Sasha Levin
2011-06-28  4:44   ` Johann Meier
2011-06-28  5:47     ` Sandy Harris
2011-06-28 19:44       ` Henrique de Moraes Holschuh
2011-06-28  6:02   ` Sandy Harris
2011-06-28 14:42     ` Ted Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110628144206.GJ2729@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandyinchina@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox