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

Bill Cox waywardgeek at gmail.com
Thu Nov 24 02:25:28 EST 2016

Note: I do believe David is honest in his stated opinions here, and I
suspect if we were allowed to dig into Intel's DRNG design, we would find
nothing sinister.  That said, I feel his opinions stated above are

On Tue, Nov 22, 2016 at 1:19 PM, <dj at deadhat.com> wrote:

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

AFAIK, there are zero cases of PWNing because servers mixed multiple
sources instead of relying on just one.

I am one of a handful of people who know for sure that RdRand is secure
> because we designed, built and tested it.

It worries me that you "know for sure" that RdRand is secure.  Do you have
the analog background to warrant that confidence?  How do you defend
against a simple power droop attack?

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.

>From what I can tell, the certifications are largely a joke.  This does not
inspire trust.

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

Just write your random data to /dev/random, and let it do the mixing.  How
does that add to the attack surface?  Mixing multiple sources is good.

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

Anybody can write the code to feed potentially random data to /dev/random.
It's easy, and even if you mess up, you have not made things worse.

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.

The trick is avoiding buggy software like Haskel and rngd that somehow have
bugs that cause them to rely exclusively on RdRand.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161123/bd07db26/attachment.html>

More information about the cryptography mailing list