RAND_DRBG

[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) 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.
> 
> The option I see are:
> 
> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking
> change.
> 2. Bypass RAND_DRBG and live with a breaking change (refer:
> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828)
> 3. Leave things as they currently are in master.
> 
> The first two are breaking changes and will require an OMC vote.
> 
> 
> Some pertinent points:
> 
> 1. RAND_bytes will continue to work as is — this API is perfect for
> almost everyone.
> 2. The RAND_METHOD functionality remains — this allows wholesale
> replacement of OpenSSL’s RNGs if desired.
> 3. The name EVP_RAND is the working name and might change — this is not
> relevant to this discussion.
> 4. The RAND_DRBG APIs are unlikely to be widely used — they were
> introduced in 1.1.1.  The two users I know of (Akamai and NCP) are both
> fine with them being removed.
> 
> 
> Thoughts anyone?
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
>