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

[Viktor Dukhovni]

> On Nov 20, 2016, at 10:55 AM, Bill Cox <waywardgeek at gmail.com> wrote:
> 
> On Sat, Nov 19, 2016 at 7:59 PM, Viktor Dukhovni <cryptography at dukhovni.org> wrote:
> 
> What is the crypto community's current state of concern around
> RDRAND?  Should Haskell's Crypto avoid seeding exclusively from
> RDRAND?
> 
> Intel's "DRNG" should not to be trusted if your threat model includes the NSA.  It remains secretive, and simple potential attacks like a "power droop" attack have not been properly addressed by Intel, IMO.  However, if you just need random-looking numbers for simulations, RDRAND is good.

Thanks Bill.

At this time, just for my own project, "random looking" numbers,
indeed even non-random looking numbers happen to be sufficient.
While learning the toolchain, I just happen to be paying close
attention to the details, in order to make sure that I'm doing
my part right.

Anyone else care to comment on the wisdom or folly of RDRAND as
a principal (sole) seeding mechanism for a TLS stack?  Note that
in this case the raw RDRAND output is never leaked directly, it
(just 40 octets of RDRAND output) is only used to seed a ChaCha
DRBG, which then provides all the randomness for a TLS context.

> Clearly, Haskell should include all attackers in its threat model.
> If what you say is true, I think the authors of that code should
> provide an explanation of how this happened.

I am quite confident that the seeding is performed as reported.

I don't think it would be fair to challenge the author for an
explanation.  Much of the Haskell ecosystem is volunteer work.
However, constructive criticism (a Github pull request with a
good quality patch) might do the trick, if the seeding method
is definitely in need of improvement.

I am perhaps still too new at Haskell to produce a "natural"
improved implementation.  My Haskell code might look too much
of Fortran. :-)  If someone else wants to give it a go, the
code in question is at:

    https://github.com/haskell-crypto/cryptonite/tree/master/Crypto/Random/Entropy

The loop that tries each backend in turn is in:

    https://github.com/haskell-crypto/cryptonite/blob/master/Crypto/Random/Entropy/Unsafe.hs

("Unsafe" here is about lack of "referential transparency"[1]),
while the backend configuration is in:

    https://github.com/haskell-crypto/cryptonite/blob/master/Crypto/Random/Entropy/Backend.hs

-- 
	Viktor.

[1] https://en.wikipedia.org/wiki/Referential_transparency
    https://wiki.haskell.org/Referential_transparency