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

[Ray Dillinger]

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.

People talk about "entropy" as though it were one thing (same against
all adversaries) but it's not.  When you need 128 bits of "entropy" you
aren't measuring (or at least shouldn't be) measuring some abstraction;
what you want is that for every possible set of attackers with *some*
inside knowledge, to make sure you're getting at least 128 bits that
that particular set of attackers wouldn't know or be able to determine.
If every last possible source of entropy on your box is known by or can
be determined by *someone*, but for each possible *someone* there's at
least one that they can't, then you can have some security as long as
your adversaries don't share information, but your security depends on
128 bits from every source in the set that is unknowable to at least one
of your adversaries.

RDRAND is provided by a single entity and can't be audited.  Therefore
that entity (in this case Intel and anybody they have possibly shared
information with) should be assumed to know exactly what bits RDRAND
provided.  Even if RDRAND is secure against everybody else, you still
need 128 bits that can't be determined by anybody in that set before you
call it 128 bits of "entropy".

For all we know, RDRAND is a deterministic generator keyed by CPU ID and
reseeded by the time each millisecond.  I do not claim that this is the
case; I claim only that it COULD be and nobody could tell the difference
from the outside.  That would be a worst-case scenario deliberately
designed as a backdoor.  If that were the case, then someone from the
"In group" who knows about the backdoor, knows what time your seed was
generated, and knows your CPU ID or MAC address (MAC can usually be
correlated with what CPU that device was installed on the same
motherboard with) can eavesdrop on your output, test a few hundred
thousand possibilities which takes less than a second, and determine
your key.


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

Doesn't matter.  ChaCha is deterministic, and therefore adds no real
randomness.  If someone knows the seed material they can predict your
ChaCha outputs forever, or if someone can see (or determine) the ChaCha
outputs they can tell whether it was seeded with a particular sequence.

> I don't think it would be fair to challenge the author for an
> explanation.  Much of the Haskell ecosystem is volunteer work.

"Volunteer work" means that you should be prepared for the possibility
that some of your "volunteers" are paid employees of your adversaries.
If I were part of the "in group" that can determine RDRAND outputs, it
would definitely be worth my money to pay someone to "volunteer" and
make sure that anything I want to crack uses RDRAND exclusively.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161121/b5abe511/attachment.sig>