linux-kernel - Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Mar 2014 07:54:25 -0500
From:	Jason Cooper <jason@...edaemon.net>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Kees Cook <keescook@...omium.org>, Theodore Ts'o <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Satoru Takeuchi <satoru.takeuchi@...il.com>,
	linux-crypto <linux-crypto@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng
 sources

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/