[openssl-dev] Work on a new RNG for OpenSSL

[John Denker]

On 06/27/2017 02:28 AM, Matt Caswell wrote:
>>
>> I also agree that, by default, using the OS provided source makes a lot
>> of sense.

Reality is more complicated than that;  see below.

On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev wrote:

> Do you mean having openssl just pass through to
> getrandom()/read()-from-'/dev/random'/etc. or just using those to seed
> our own thing?
> 
> The former seems simpler and preferable to me (perhaps modulo linux's
> broken idea about "running out of entropy")

That's a pretty big modulus.  As I wrote over on the crypto list:

The xenial 16.04 LTS manpage for getrandom(2) says quite explicitly:

>> Unnecessarily reading large quantities  of data will have a
>> negative impact on other users of the /dev/random and /dev/urandom
>> devices.

And that's an understatement.  Whether unnecessary or not, reading
not-particularly-large quantities of data is tantamount to a
denial of service attack against /dev/random and against its
upstream sources of randomness.

No later LTS is available.  Reference:
  http://manpages.ubuntu.com/manpages/xenial/man2/getrandom.2.html

Recently there has been some progress on this, as reflected in in
the zesty 17.04 manpage:
  http://manpages.ubuntu.com/manpages/zesty/man2/getrandom.2.html

However, in the meantime openssl needs to run on the platforms that
are out there, which includes a very wide range of platforms.

It could be argued that the best *long-term* strategy is to file
a flurry of bug reports against the various kernel RNGs, and then
at some *later* date rely on whatever the kernel provides ... but
still, in the meantime openssl needs to run on the platforms that
are out there.