[openssl-dev] Plea for a new public OpenSSL RNG API

[Dr. Stephen Henson]

On Tue, Aug 29, 2017, Richard Levitte wrote:

> I'm late in the game, having only followed the development very
> superficially...
> 
> If I understand correctly, the RAND_DRBG API is really a completely
> separate API that has nothing to do with the RAND_METHOD API pers se,
> i.e. any association between the two is more or less "accidental"?
> 
> Frankly, I cannot see anything wrong with making that a public API.  I
> wonder, though, if this is going to be an implementation that's kinda
> sorta built-in only, or if other implementations of the basic stuff
> will be possible...  or in other words, will we have a "method"
> structure like we have with so many other APIs?  In saying this, I'm
> counting in the possibility that some implementations could come in
> the form of engines, is this something that's been thought about?  I
> do notive the DRGB_CTX structure, but that doesn't quite follow the
> usual "method" pattern we have...
> 

In terms of future FIPS 140-2 compliance having a way to redirect all PRNG
operations to a FIPS compliant version is essential. This would require some
kind of method. We can redirect via RAND_METHOD but that currently means that
any ENGINE supplied PRNG is severely restricted (one global PRNG only)
compared to the built in DRBG. We could resolve that via a DRBG_METHOD or some
extended RAND_METHOD.

That's for the future though: there wont be a new FIPS module for some time
that will need this functionality.

In terms of the API itself. We could make RAND_DRBG public and I can see
reasons both for and against that. The main objection I can see is that it
commits us to DRBG like PRNGs: that is if we (or an ENGINE) in future wants to
use a RNG that isn't a good fit for the DRBG API it's a problem. We're
partially hitting that now because the DRBG API is not a good fit for the
older RAND API.

One alternative is to expand RAND_METHOD so it treats a DRBG as a special case
of the expanded API and it is flexible enough to handle any future needs. That
would (for example) have extended RAND APIs which can be passed an "instance"
of a PRNG (something like RAND_CTX which is analagous to the DRBG instance
structure we currently have).

That is tricky because RAND_METHOD is alas not an opaque structure and can't
be made so before OpenSSL 1.2.0. Tricky but not impossible.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org