Re: Lightweight support for instruction RNGs

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On 19 December 2015 at 17:10, Thor Lancelot Simon <tls%panix.com@localhost> 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.

> I would not expect the LFSR pool output to pass dieharder, no matter
> what input is mixed into it.  Conversely, it's nuts to expect the output
> of SHA1 to fail it, and the same goes for the CTR_DRBG.
>
> There would appear to be no suitable place to connect the test rig you're
> suggesting.  If the statistical properties of the output of either SHA1
> or AES (the core of the CTR_DRBG) detectable differ according to the _input_
> to those functions, everyone in the world's got a heck of a problem.  If
> they don't, then we have nowhere we can attach dieharder to see what you
> want to look for.
>
> The only reasonable thing to run dieharder on is the output of the CPU
> instruction itself.  But one does not need to be in the kernel to do that
> (for the Intel instructions in any case; we could perhaps add a tap to
> dispense the output of the VIA "xstorrng").

I do know there is distrust of RDRAND in general, and I want to make
sure that the combined output is not skewed in any way. Simply saying
that you hope that the output is random is not something I can accept.
Frankly, it's not something you should be trusting either. Just run
the damn thing - what's the problem with that?

>> As to how it's hooked up - either present dieharder with a file of
>> random bytes which you've generated using your new rng (via the -f
>> filename parameter), or use one of the generators - you run it with -g
>> -1 to produce a list of possible generators:
>
> There is no "new rng".  This still makes no sense to me at all.

You have changes you want to make to our rng inputs. There is an
existing rng. It's not hard to work out what I mean here. Just as it's
not hard to run a before and after.

I know you don't expect running it to show anything. I'm not sure what
I expect. But that's not a good reason not to run any automatic test
that we can.