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 _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project