From: Jason Cooper <jason@lakedaemon.net>
To: Matt Mackall <mpm@selenic.com>
Cc: Kees Cook <keescook@chromium.org>,
"Theodore Ts'o" <tytso@mit.edu>,
LKML <linux-kernel@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Rusty Russell <rusty@rustcorp.com.au>,
Satoru Takeuchi <satoru.takeuchi@gmail.com>,
linux-crypto <linux-crypto@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources
Date: Thu, 6 Mar 2014 07:54:25 -0500 [thread overview]
Message-ID: <20140306125425.GZ1872@titan.lakedaemon.net> (raw)
In-Reply-To: <1394067147.17842.45.camel@calx>
On Wed, Mar 05, 2014 at 06:52:27PM -0600, Matt Mackall wrote:
> On Wed, 2014-03-05 at 16:11 -0500, Jason Cooper wrote:
> > > In other words, if there are 4096 bits of "unknownness" in X to start
> > > with, and I can get those same 4096 bits of "unknownness" back by
> > > unmixing X' and Y, then there must still be 4096 bits of "unknownness"
> > > in X'. If X' is 4096 bits long, then we've just proven that
> > > reversibility means the attacker can know nothing about the contents of
> > > X' by his choice of Y.
> >
> > Well, this reinforces my comfortability with loadable modules. The pool
> > is already initialized by the point at which the driver is loaded.
> >
> > Unfortunately, any of the drivers in hw_random can be built in. When
> > built in, hwrng_register is going to be called during the kernel
> > initialization process. In that case, the unknownness in X is not 4096
> > bits, but far less. Also, the items that may have seeded X (MAC addr,
> > time, etc) are discoverable by a potential attacker. This is also well
> > before random-seed has been fed in.
>
> To which I would respond.. so?
I only saw this line of context pop on my phone last night, and that led
me to a train of thought. In short, I agree with you, and I actually
now prefer Kees patch in it's original form.
> If the pool is in an attacker-knowable state at early boot, adding
> attacker-controlled data does not make the situation any worse. In fact,
> if the attacker has less-than-perfect control of the inputs, mixing more
> things in will make things exponentially harder for the attacker.
Just to clarify my understanding: Say we have inputs A, B, C, W, X, Y,
Z. A, B are known to the attacker (MAC address, etc), C is the attacker
known hwrng data. W-Z are small chunks added in from unpredictable
events.
In order to predict a potential set of states at boot, the attacker not
only has to brute force W-Z, but also the order of A-C,W-Z.
Without C, the order of the events becomes more deterministic. Thus
making the job easier for the attacker.
> Put another way: mixing can't ever removes unknownness from the pool, it
> can only add more. So the only reason you should ever choose not to mix
> something into the pool is performance.
I also need to clarify an assumption I made in this thread. I focused
too heavily on Attacker1, who has secret knowledge of the internal
workings of the hwrng. As we've established above, his job isn't made
easier by adding hwrng data during system boot.
In addition, Attacker2 through AttackerN who _don't_ have the secret
knowledge of the hwrng, but do know the MAC address and other initial
inputs are defeated by adding the hwrng during system boot.
Matt, thanks for taking the time to come out of retirement to help us
with this. Kees, thanks for your patience :)
thx,
Jason.
next prev parent reply other threads:[~2014-03-06 12:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 23:51 Kees Cook
2014-03-04 15:38 ` Jason Cooper
2014-03-04 19:01 ` Kees Cook
2014-03-04 19:53 ` Jason Cooper
2014-03-04 19:59 ` Kees Cook
2014-03-04 22:39 ` Matt Mackall
2014-03-05 21:11 ` Jason Cooper
2014-03-05 21:51 ` Kees Cook
2014-03-06 0:52 ` Matt Mackall
2014-03-06 1:34 ` Kees Cook
2014-03-06 12:54 ` Jason Cooper [this message]
2014-03-17 2:12 ` H. Peter Anvin
2014-03-06 12:55 ` Jason Cooper
2014-03-10 12:22 ` Herbert Xu
2014-03-16 22:56 ` H. Peter Anvin
2014-03-17 11:53 ` Austin S Hemmelgarn
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=20140306125425.GZ1872@titan.lakedaemon.net \
--to=jason@lakedaemon.net \
--cc=akpm@linux-foundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=rusty@rustcorp.com.au \
--cc=satoru.takeuchi@gmail.com \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®