[openssl-users] RNG behavior by default

[Kurt Roeckx]

On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote:
> 
> (I am also really interested and will look into OpenSSL to see if
> the abort() that seems to happen if the initial seed fails is in
> a linker-resolved constructor, and if not, why later failures do
> not also abort.

We do not call abort(). A function like RAND_bytes() or
RAND_status() will just return an error.

> Yes, while i am going, the full truth is that
> i do not like it, i do not like that possibly a constructor call
> is made for something that is possibly not needed, if it is done
> like that, that someone simply aborts because of a some internal
> PRNG, especially so if it is not in a constructor call and if
> errors can and are expected to be handled by PRNG users anyway,

RAND_bytes() has always documented that it can fail. Most function
calls can return errors for various reasons. Not checking for such
errors is in my opinion a bad style.

> i do not like that the stuff is instantiated in all threads

It's only created in each thread that tries to the RNG. I'm not
sure what exactly your problem with it is. Either we need a global
lock, or we need an RNG per thread. We went with the per thread
RNG.

We have a master DRBG that you can get with
RAND_DRBG_get0_master(). I recommend that you do not use it. It
requires that you take an external lock to use it. Internally we
lock it, but there is no way for you to use the same lock.

> which
> in addition requires forks handlers to be installed all over the
> place.

OpenSSL adds it's own fork handler now. You should not need to do
anything on fork related to OpenSSL.

> the Linux kernel that drives
> the world from smallest to hugest has one internal entropy pool
> that feeds two public pools, whereas i the lucent little hobby
> server from user space get an armada of these.  Wow.

Linux has a master pool, and a pool per core for the very same
reason as we also have a master DRBG and per thread DRBG.


Kurt