[Cryptography] OpenSSL and random

John Denker jsd at av8n.com
Wed Nov 30 14:43:30 EST 2016


On 11/30/2016 06:59 AM, Bill Cox wrote:

> I just learned on another thread that Linux provided a fixed API.  The new
> right answer on Linux is to call getrandom:

Similarly on 11/30/2016 06:27 AM, Bill Cox wrote:
> The right answer on Linux is now:
> 
> Just call getrandom

And on 11/30/2016 11:23 AM, Ray Dillinger wrote:
>>  the short version of the story is
>> that getrandom() blocks unless sufficient initial entropy has been
>> collected, but is nonblocking forever after.  Which is, IMO, the right
>> thing. 

If that suits _your_ purposes, congratulations ... but no, it is not
the right answer for openssl, and never will be, for reasons that
Rich Salz and others have pointed out:

  Given an RNG that blocks, a great many users won't tolerate it
  in any critical path.  Instead they will roll their own PRNG,
  with predictably terrible results.  A library must not foist a
  blocking RNG on its users.

  The Right Answerâ„¢ is to procure a RNG that just never blocks
  under any relevant conditions.  This is not easy, but it is
  doable on most platforms.

     There will always be some platforms that are not secure and
     cannot be made secure, but we must not let this derail our
     train of thought.

I say again:  /dev/random must learn to never block, and /dev/urandom
must learn to never emit untrustworthy bits, whereupon the specification
is the same for both.  The same goes for getrandom() and getentropy():
they must never block, and they must never emit untrustworthy bits.

I'm not saying this is easy, but it has to be done.  Anything short
of this fails to solve the problem faced by a great many apps and
libraries (e.g. openssl).


FreeBSD has been mentioned.  They got this _partly/ right.  Their
/dev/random and /dev/urandom are synonymous, which is a step in the
right direction, but both may block, rather like getrandom(), which
is just not good enough for critical applications.



More information about the cryptography mailing list