[Cryptography] randomness for libraries, e.g. OpenSSL
nico at cryptonector.com
Mon Nov 28 22:48:06 EST 2016
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.
More information about the cryptography