RAND_DRBG futures

2020-08-03 Thread Dr Paul Dale
I’ve closed the vote. Five for, none against, the vote passes. RAND_DRBG will be absent in 3.0. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia

Re: RAND_DRBG

2020-07-27 Thread Dr Paul Dale
option 1 (but it will require a vote). I think the > percentage of our user base that are using the existing API is > sufficiently close to zero that we're not breaking our compatibility > promises. > > Matt > > > On 27/07/2020 02:08, Dr Paul Dale wrote: >> The RAND_DRBG (cr

Re: RAND_DRBG

2020-07-27 Thread Matt Caswell
I'm ok with option 1 (but it will require a vote). I think the percentage of our user base that are using the existing API is sufficiently close to zero that we're not breaking our compatibility promises. Matt On 27/07/2020 02:08, Dr Paul Dale wrote: > The RAND_DRBG (crypto/rand/drbg_lib) A

Re: RAND_DRBG

2020-07-27 Thread Tomas Mraz
e the same is a few lines of code >and is likely to occur in one place in an app, then it seems reasonable >to change it to me. >> >> >>> On 27 Jul 2020, at 11:08 am, Dr Paul Dale <mailto:paul.d...@oracle.com>> wrote: >>> >>> The RAND_DRBG (

RE: RAND_DRBG

2020-07-27 Thread Dr. Matthias St. Pierre
> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly > with the move to provider based infrastructure. Actually, it is not the RAND_DRBG API itself (as it is in 1.1.1) which is messy. It’s the fact that part of its interface is very low level and that the EV

Re: RAND_DRBG

2020-07-26 Thread SHANE LONTIS
eems reasonable to change it to me. > > >> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > <mailto:paul.d...@oracle.com>> wrote: >> >> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly >> with the move to provider based infrastr

Re: RAND_DRBG

2020-07-26 Thread SHANE LONTIS
If this is not going to break 99% of users + it improves the interface + the replacement to achieve the same is a few lines of code and is likely to occur in one place in an app, then it seems reasonable to change it to me. > On 27 Jul 2020, at 11:08 am, Dr Paul Dale wrote: > > The

RAND_DRBG

2020-07-26 Thread Dr Paul Dale
The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly with the move to provider based infrastructure. They are definitely being deprecated in master but without more, the extra layer of indirection and additional complexity generating random numbers will remain

[openssl-project] Merge conflicts caused by pull request #5462 - Publish the RAND_DRBG API

2018-03-15 Thread Dr. Matthias St. Pierre
Hi, in a few hours I will merge pull request   #5462 - Publish the RAND_DRBG API This pull request removes 14 public symbols (symbols RAND_POOL_*,  numbers 4351 - 4364) and closes the gap by renumbering all following symbols. Anyone of you who as added new symbols to libcrypto.num in his pull