[openssl-project] DRBGs, threads and locking

[Kurt Roeckx]

So Tim has voted -1 on PR #5547 and wants us to discuss it here
and vote on it.

I don't know if it's clear to everybody what this is about. If
something is not clear, please ask. PR #5461 contains a
lot of documentation updates that is related to it, and it might
be useful to read it as background information. There are many
other related issues and pull request. I will try to make a basic
summary here.

The DRBGs is what we use to generate random numbers. They have the
possibility to chain, where 1 DRBG gets it's entropy from it's
parent. You can make long chains with this.

The current state in master is that you have 1 master DRBG that
gets it's entropy from the OS, and then 1 public and 1 private
DRBG that gets the entropy from the master. Then there is an DRBG
in the SSL struct that gets it's entropy from the public DRBG.

I have 2 problems with the current setup that I would like to
solve:
- On SSL_new() we create a new DRBG. That needs to get initialized
  and that requires getting entropy from somewhere, where that's
  currently the global public DRBG. This requires taking a lock.
- If we actually want to use the DRBG for everything related to
  that SSL connections to avoid having to lock a global DRBG
  everything that SSL code calls needs to be able to say with
  which DRBG it needs to generate random data. There was already 1
  PR related to this merged. PR #5510 is still open that deals at
  least with mot of it that I know about. I find that a very ugly
  hack and really don't see an easy way improve it.

My solution is to just have 1 master DRBG, and a public and
private DRBG per thread. The only lock that then is needed is when
the public or private DRBG needs to reseed. All the rest of the
code can stay just as it is, but we might want to change some
places to use the (thread local) private DRBG, which is what #4665
is about.

Some people seem to have a desire to have a separate the DRBGs per
SSL connection, at least for the public data. This is for cases
where from that data it would be possible to get the internal
state of the DRBG that is at least allegedly possible with the
DUAL_EC_DRBG. I believe this is mitigated somewhat by our mixing
in additional data when calling RAND_bytes() (or RAND_priv_bytes()),
but I'm not an expert in this and will leave this to the others to
comment on.

So the suggestion was to still have a per SSL public DRBG, but
then the problem is that that SSL object might have moved to a
different thread between creating and being used and so that the
parent DRBG might actually belong to a different thread. One
solution there is that we just take the current thread's public
DRBG as parent instead of the original threads public DRBG.


I hope I at least covered most of it.


Kurt