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

[Bill Cox]

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.

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 find it disturbing that this same bug keeps showing up.  I found the
exact same bug in rngd, the standard Linux deamon for gathering entropy
from true random number generators: rngd.  The authors and maintainers of
rngd I think owe us an explanation as well.  Has it been fixed yet?

As for Intel's DRNG, there are no published attacks against it AFAIK, and I
doubt there will be any - it is just too difficult to reverse-engineer.
However, it is negligent to build a random number source that could be used
for cryptography that relies only on Intel's secretive RNG for entropy.

My best guess is the Intel designers did an honest job of Intel's DRNG, but
I never did get a competent answer to how they would defend against a
trivial power-droop attack, where the CPU just does a ton of
multiplications in a loop for a while.  The incompetent answer provided was
that back-to-back inverters naturally provide high power supply rejection.
Now days, this is simply not true, because side-by-side transistors usually
have significantly different thresholds.  They could easily counter this
problem with large slow transistors, but given the speed they run, clearly
they did not.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161120/1c981e33/attachment.html>