So far a universal voice for removal of the DRBG_RAND APIs. I’ll write up an OMC vote.
Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 27 Jul 2020, at 6:51 pm, Matt Caswell <m...@openssl.org> wrote: > > 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 >>
