[Cryptography] Use of RDRAND in Haskell's TLS RNG?

[dj at deadhat.com]

>
>
> On 11/20/2016 12:57 PM, Viktor Dukhovni wrote:
>
>> Anyone else care to comment on the wisdom or folly of RDRAND as
>> a principal (sole) seeding mechanism for a TLS stack?
>
> Don't do that.  It is folly to rely on any *single* source as a
> seeding mechanism.
>

It's a mixed bag.

I am one of a handful of people who know for sure that RdRand is secure
because we designed, built and tested it. So I'm happy to use it and I do.
Other people have to trust it and their basis of trust should be the
independent audit, researcher reviews and SP800-90 certifications which to
a greater or lesser extent mean people have looked at it and declared it
to be exactly what it claims to be.

If you instead choose to get your random numbers from your OS, that gets
those random numbers from RdRand, all the OS is doing is adding attack
surface and reducing performance.

The OS can provide a useful service by combining multiple sources, but
they have to (a) have those multiple sources (b) know how to get at them
and (c) do it right.

A library or the language compile could combine sources if they know how,
but subject to the same constraints.

If you are sufficiently paranoid, you could choose to combine multiple
sources yourself in the hope that at least one of them is secure. I have
developed software that does exactly that for applications that requested
it. To do that yourself you should study extractor theory to understand
how to combine sources. Don't believe anyone who says "just XOR them
together". For imperfect sources or malicious sources, that probably will
not work as intended. XORing certainly can make things worse, especially
when sources are not independent, as you typically find with RO sources
subject to the same supply noise. "Just hashing it" will probably do, but
there is zero mathematical evidence that it will do and extractor theory
says otherwise.

However one technical problem surfaced early on for practically combining
RdRand output with other sources in software. Most physical sources are
very slow compared to the multi gigabit/s source used by the circuit that
feeds RdRand and they can be slower still because the post processing is
done in software and lower quality because the extractor is often simply
wrong, like using a twisted LFSR or a Von Neumann whitener or a Yuval
Perez  whitener, all of which don't work as intended when fed data from
serially correlated sources (which is practically all of them) . You might
want to check for that.

So when you choose to combine 1 second worth of data from RdRand with 1
second worth of data from your undersampled ring oscillator, you end up
with 800MBytes of RdRand data and a couple of kilobits of data from the
other source. You can choose to lower the performance to the slowest
source you have and if that's ok and you're using a good extractor, you'll
be ok.

I'd point you to a good book on extractor theory, but I haven't finished
writing it yet, sorry and I can't make any guarantees as to whether or not
it is good.

DJ