RAND_DRBG

[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 EVP_RAND interface tries to move away from that. In particular, in the future seed sources will be pluggable by chaining
the primary DRBG to an entropy source which is provided as a fetchable EVP_RAND interface, not by replacing some internal callbacks.
(Note however, that fetchable entropy sources,  in particular sources of low quality, are not implemented yet and won’t be implemented
in time for version 3.0. But as far as I’m concerned, I can wait for 3.1, since my company is still transitioning from 1.0.2 to 1.1.1. )

Moving to the new approach while at the same time having to retain compatibility to the old approach, that’s what is creating the mess
under the hood. Most notably, it’s the two functions RAND_DRBG_set_callbacks() and RAND_DRBG_set() which are creating the problems.
Pull Request #12509 attempts to untangle the two RNG interfaces by providing two unrelated triples of RNGs (option 2 in Pauli’s proposal),
an EVP_RAND triple and a RAND_DRBG triple. This does not work out well, as pointed out by me in [1]. There might be a variant of option (2)
however to fix the problem described in [1], which could provide better compatibility:

4. Offer legacy RAND_METHOD (e.g. RAND_drbg_method(), RAND_OpenSSL_legacy(), …) as an alternative to RAND_OpenSSL()

Anybody who currently uses the RAND_DRBG callback mechanism, could activate this legacy RAND_METHOD to switch from the new
EVP_RAND triple to the legacy RAND_DRBG triple of random generators, and their callbacks would continue to work as expected.

I still favour option (1), but (4) might be a reasonable compromise. It comes at a price, because both RAND_METHODs need to be fully
supported  and tested thoroughly.

Matthias


[1] https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828

From: openssl-project <openssl-project-bounces at openssl.org> On Behalf Of Dr Paul Dale
Sent: Monday, July 27, 2020 3:08 AM
To: openssl-project at openssl.org
Subject: RAND_DRBG

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/20200727/4de62c76/attachment-0001.html>