We did a performance analysis for Oracle’s equivalent of Nginx, OTD, about two
years ago. We were looking at the number of connections per second that could
be established and the limiting factor was locking in ssleay_rand_bytes.
Approximately a third of the CPU and over 90% of the lock wait
I think the intention is to ditch the drbg from the ssl object and then call
the global function (either public or private) which has been changed to use
the current thread's drbg rather than being global.
I'm in favour of a single per ssl drbg still, I'm not sure what a clean way to
hook it
We have to keep in mind what threats we care about and their practicality.
The security of a DRBG is dependent on both the secrecy of the seed
material provided and the security of the algorithm in terms of its output
not leaking information that materially leaks the internal state in a
manner
So a major reason, as you explained, for having per-thread DRBG's is to reduce
contention. When threadA creates an SSL object, the parent DRBG will be the
threadA one. Therefore you have to introducing locking, since threadA might
create two SSL objects and they could end up being used in
On Wed, Mar 14, 2018 at 01:27:47AM +0100, Kurt Roeckx wrote:
> 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
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
This discussion has been taken to the OMC mailing list (where it continues)
rather than the openssl-project list as it goes across previous team
decisions.
An update once that discussion completes will be sent to the
openssl-project list.
Thanks,
Tim.
On Tue, Mar 13, 2018 at 11:22 AM, Salz,
