RAND_DRBG

[Dr Paul Dale]

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 <matt at 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
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200728/67085eb1/attachment.html>