This is a followup to #4328 and #4402. As I said previously on many occasions, it is my vision and my belief that the RAND_DRBG API should become a public object oriented OpenSSL API.

The RAND_DRBG API is clearly more low-level than the RAND_METHOD API, so it makes sense to place the RAND_DRBG declarations in a separate header <openssl/rand_drbg.h> distinct from <openssl/rand.h> and make it clear in the documentation that this API is intended for “back end” developers, like somebody who tries to integrate a hardware RNG as entropy source and not for the standard user.

This issue does not compete with issue #4394. Having a simplified API for plugging in standard or user-defined entropy sources is a good way for 90% of the use cases. But there are also cases, where one needs access to the full power of the RAND_DRBG API. For example, in one of our products the default RAND_METHOD is mapped to a DRBG which reseeds on every generate request (prediction_resistance = true) and pulls its entropy from a smartcard (/dev/random is only used as additional input). Such special cases can only be handled with the full API.

The RAND_DRBG should be a full blown "class", i.e. the structure should be opaque with the necessary accessors. To be truly object oriented, the rwlock needs to be owned by the object, and the locking managed entirely by the RAND_DRBG's "methods" (please excuse my C++-speak) and not by the caller.

The libcrypto library is a low level general purpose crypto library. So it should provide a toolbox of useful algorithms and not make any assumptions about the way it will be used by the programmer. In particular, it should enable but not force the programmer to use the legacy RAND_METHOD api.