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

Watson Ladd watsonbladd at gmail.com
Sat Nov 26 07:06:43 EST 2016


On Thu, Nov 24, 2016 at 2:25 AM, Bill Cox <waywardgeek at gmail.com> wrote:
> 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
> dangerous.
>
> 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?

Have you looked at the RDRAND circuit and the on-chip power
distribution network? Your claimed "simple power droop attack" depends
on the output impedance of the power supply and the variance in the
current consumption caused by your instructions. Both are potentially
knowable: did you do the work to know them? Then you have to explain
how your "simple" attack avoids the on chip health checks.

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

Does /dev/random actually mix the entropy correctly? Does /deve/random
protect against malicious sources? Actual history indicates neither of
these assumptions are true.

>
>>
>> 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.
>
> Bill
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.


More information about the cryptography mailing list