Re: Lightweight support for instruction RNGs

Have you tried running this with pkgsrc/math/dieharder? I'd be
interested to see the results (the current version in pkgsrc -- 3.31.1
-- is much better than the previous one, and displays its results in a
much more useful way than previously). Not the be-all and end-all, but
still worthwhile running it.

Best,
Alistair

On 19 December 2015 at 16:37, Thor Lancelot Simon <[email protected]> wrote:
> I was playing with code for a RDRAND/RDSEED entropy source and it
> just felt like -- much like opencrypto is poorly suited for crypto
> via unprivileged CPU instructions -- our rndsource interface is
> a little too heavy for CPU RNGs implemented as instructions.
>
> I came up with the attached, which mixes in entropy from a new
> "cpu_rng" each time samples are added to the global rndpool.
>
> On the downside, this means we don't get statistics for this source.
>
> On the upside, the cost of the stats-keeping vastly exceeds the cost
> of the entropy generation, at least for the Intel implementation; I'm
> less sure about VIA.
>
> Another downside is that you can't turn this source on and off; but
> on the upside, it's never used _except_ when samples from other sources
> are being mixed in at the same time, so that should not be a cause for
> security concern.
>
> Needless to say, the real benefit here is that we get up to 64 bits
> of additional entropy along with every other sample, without paying
> any additional locking or synchronization overhead.
>
> I've tested the RDRAND code.  The RDSEED code is almost identical but
> I don't have a CPU with RDSEED handy.  The VIA code is lifted almost
> verbatim from the existing PadLock driver, but I no longer have a VIA
> board to test with -- I'd appreciate help with that.
>
> If this looks like a good idea, before committing it I'll make
> cpu_rng_init a do a little more work -- specifically, an entropy
> test is probably in order.
>
> Thor