Re: Lightweight support for instruction RNGs

[Thor Lancelot Simon <tls%panix.com@localhost>]

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.

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").

> 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.

Thor