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

[ianG]

On 28/11/2016 16:37, 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 messages here ... you shouldn't trust it.


Right.  So Intel provided the hardware and it has weaknesses.  This is 
the same as other vendors providing the hardware, all hardware RNGs come 
with weaknesses.  Hence the need to pool & mix.

>  So what's the next step?

The answer circulates around an assumption - what is the platform that 
is the appropriate place to fix the RNG problem?  Is it Intel, which is 
clearly a platform and it fixes the problem with RDRAND, or is it 
OpenSSL which apps see as a crypto platform, or is it Linux?

The answer is I think - the platform that is lowest layer, in software, 
and in open source.  Everything below is out-of-control hardware, so can 
be seen as a separate source of entropy.  Everything above is user software.

Which makes it Linux.  Or *BSD or Windows.  Is where the problem should 
most efficiently be solved.

> (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*?)

Right.  When it gets to hardware, we are not only looking for an audit, 
we are totally dependent on it.  Which is not a good thing - and 
hardware therefore has this special status - mysterious, vaguely 
hopeful, branded.

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

Sure - but a standard source at a platform level like urandom is not 
easy for Intel to futz with.  It is issues like this that make the 
platform of efficient rectification open source.

If the RNG mix is in the OS, then Intel's chip has to look at the code, 
analyse where the RNGs are being mixed, and then dive in and futz with 
the instructions as they are coming out of the mixer.

Crazy, but doable in some corner of the 8bn transisters.  IIRC the 
permathread from about 3 years back, this argument came up when RDRAND 
was being treated as a post-mix action in Linux.  As RDRAND was now the 
last thing, it was somewhat more credible that an internal analysis 
could trigger just on RDRAND.

At the time I think it was acknowledged.  And RDRAND got pushed back 
upstream into the mix - or so it was intimated at the time.  Ideally, 
RDRAND should be "just another pluggable mixer".  And to amuse this 
group here, Linux could also be customarily pushing a series of changes 
... and forcing the NSA to live-update its internal microcode to keep up :)



iang