the numbers yet :(
Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
From: Tim Hudson [mailto:t...@cryptsoft.com]
Sent: Wednesday, 14 March 2018 1:15 PM
To: openssl-project@openssl.org
Subject: Re: [openssl-project] DRBGs, thr
On Wed, Mar 14, 2018 at 12:49:46PM +, Salz, Rich wrote:
> So is having a high-quality, lockless (per-thread) CSPRNG good enough for
> now? Phrased like that, I think so. We have enough other stuff to do. So
> +1 to Kurt's per-thread approach.
I think it's better than what we have in
So is having a high-quality, lockless (per-thread) CSPRNG good enough for now?
Phrased like that, I think so. We have enough other stuff to do. So +1 to
Kurt's per-thread approach.
___
openssl-project mailing list
openssl-project@openssl.org
It is good that Tim hit the break and requested a discussion. That was
overdue and it is unfortunate that we did not start it much earlier. I
think Tim brought up to important points:
1. We need to to pause for a discussion to determine the direction to
go. Otherwise the DRBG implementation will
Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
From: Tim Hudson [mailto:t...@cryptsoft.com]
Sent: Wednesday, 14 March 2018 1:15 PM
To: openssl-project@openssl.org
Subject: Re: [openssl-project] DRBGs, threads and locking
We have to keep in
ject: Re: [openssl-project] DRBGs, threads and locking
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
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
