Re: Lightweight support for instruction RNGs

On Sat, Dec 19, 2015 at 05:23:58PM -0800, Alistair Crooks wrote:
> On 19 December 2015 at 17:10, Thor Lancelot Simon <[email protected]> wrote:
> > On Sat, Dec 19, 2015 at 04:54:20PM -0800, Alistair Crooks wrote:
> >> The point is to see if RDRAND plus other inputs does not regress to
> >> produce an output that is, in some way, "predictable". And while
> >> running dieharder does not guarantee this, it may show up something
> >> unusual. Given that there's previous history in this area, I'd
> >> consider it a prudent thing to do.
> >
> > You understand, I hope, how the relevant machinery works.  Samples are
> > mixed together in a very large state pool which is a collection of LFSRs,
> > then hashed with SHA1 before output.
> >
> > We then use _that_ output to key the NIST CTR_DRBG.
> 
> And to just expect that everything is mixed in as hoped, with nothing
> being missed out because of coding errors, is something I should be
> embracing, and feel better "just because"? Thanks, but we've been
> bitten that way once before. I want to make sure we're not bitten that
> way once again. I can't believe there's pushback on this. Lessons
> learned, etc.

There's pushback because you're suggesting doing something that's pure
security theater, with no value.  We've had several bugs in the RNG; we've
never had a bug in the RNG that would have actually caused Dieharder
failures!

The construction is not amenable to being tested in the way you suggest
unless one just wants to *say* one tested it without doing any test that
is meaningful -- in other words, engage in security theater.  I will not
do that.

So, I'm asking you what I asked you before: where exactly do you want
the test rig hooked up to this thing?  I'll remind you:

	* The RDRAND values should be expected to *pass* the tests even
	  if the generator is untrustworthy.

	* The raw LFSR output should be expected to *fail* these tests.

	* The SHA1 output should be expected to *pass* the tests even if
	  it is in fact not safe, due to bugs new or old, properties of
	  its input, or any other reason.

	* The CTR_DRBG output has the same properties in this regard as
	  the SHA1 output -- only more so.

I am not going to do security theater, and you are the one proposing
the test, so since you think it has value, please, tell me where
exactly to extract the output for testing, and I'll give it a shot.

Please appreciate that this means quite a bit of work to dump output
from the kernel in places where it is deliberately *not* made available
to userspace, and that the test you propose, as far as I can tell:

	* Would not have caught any of the RNG bugs we or anyone else 
	  have had in the past

	* Would not, according to any hypothesis you've been willing
	  to put forward, catch any bug we or anyone else are likely
	  to have in the future

I'll do it, but all the rhetoric you're spitting out looks like pure
marketing to me, because what you're proposing looks like pure
theater; no actual security value.  That's not the you I know, so
I must be missing something -- what is it?

Thor