[Cryptography] randomness for libraries, e.g. OpenSSL

[Nico Williams]

On Mon, Nov 28, 2016 at 04:37:46PM -0500, Jerry Leichter wrote:
> >> As a corollary:  We need to to inveigle the OS providers and
> >> hardware providers to solve the problem.
> >
> > That.  Rather than spending energy on solving the problem in code,
> > which is a really hard objective because of many factors, some of
> > which are listed below, put the energy into Inveiglement....
>
> Ahem.  Intel went and provided the hardware.  And if you read the

Agreed.  We should use it.

> messages here ... you shouldn't trust it.  So what's the next step?

Adding other sources of entropy is a no-brainer.

> (Audibility is a fine idea ... but how many people in the world have
> the knowledge, and access to the equipment, needed to check *the
> actual implementation on a state of the art chip*?)

Well, but not *everone* has to have that capability.  Many can
understand the design.  Very few can tear down a chip and verify it.
That a few labs do would be a lot better than that none do.  Granted,
that might not be saying much if it's just two labs subject to nation
state pressure, but it's still better than nothing.

> BTW, if we agree on a standard protocol for an external "random
> source" ... who's to say the next Intel chips won't recognize that
> standard protocol and send the bits being generated off to some some
> server in Utah or Russia or China?

There's a limit to how much intelligence can be baked into an ME's
flash.  One may have to resort to constantly updating such a protocol
and code for it, but that would be a very worst-case scenario.  (Not
unlike gaming and cheating, actually..., but it'd be hard for Intel to
"cheat" so much.)  In any case, a remote source of entropy can't raise
local entropy, but it can't hurt either (assuming a decent CSPRNG).
Remote sources of entropy can be all sorts of innocent-looking things,
such as search engine stats, news pages, and so on.

Nico
--