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

[Matt Caswell]

On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
> Currently, the OpenSSL core members seem to be reluctant to make the
> API public, at least at this early stage. I understand Rich Salz's
> viewpoint that this requires a thorough discussion, because a public
> interface can't be easily changed and wrong decisions in the early
> phase can become a heavy burdon.

FWIW, I am not against making the API public although I too understand
Rich's reluctance. However it seems inevitable to me that sooner or
later this API will have to be made accessible and I see little benefit
in delaying that and plenty of reasons for doing it now (it only
frustrates those that know the functionality is there but can't get at
it :-)). There is always a risk with every API added that you get it
wrong, and then you are stuck with it for ever more. The only real
answers to this are:

1) Make sure you "design" your API to start with and get it reviewed
2) Encourage people to try the API while it is still in dev i.e. so we
can still change it before the final release.

I'm not really convinced that keeping the API hidden now will mean that
it will be better in some future release. It just delays the point at
which we have the realisation of "if only we had designed it like *this*
it would have been soooo much better". Better is to make it public in
dev asap. If there are problems with it we can always revert it before
it makes it into a release.

> The 'RAND_add()/RAND_bytes()' pattern is broken 
> ===============================================
> 
> In OpenSSL, the classical way for the RNG consumer to add his own
> randomness is to call 'RAND_add()' before calling 'RAND_bytes()'. If
> the new 'RAND_OpenSSL()' method (the "compatibility layer" hiding the
> public RAND_DRBG instance)  is the default, then this does not work
> as expected anymore:
> 
> The reason is that a call to 'RAND_add()' adds the provided
> randomness only to a global buffer ('rand_bytes'), from which it will
> be pulled during the next reseed. But no reseed is triggered. So the
> next RAND_bytes() call will be unaffected from the RAND_add(), which
> is not what the consumer expected. (The same holds for 'RAND_seed()',
> since 'drbg_seed()' only calls into 'drbg_add()')
> 
> Reseeding of DRBGs occurs only at the following occasions:
> 
> * immediately after a 'fork()' (new) * if the 'reseed_counter'
> exceeds the 'reseed_interval' * if 'RAND_DRBG_generate()' is called
> requesting 'prediction_resistance' * 'RAND_DRBG_reseed()' is called
> explicitely
> 
> *Note:* Currently it looks like the situation is even worse: if
> 'RAND_add()' is called multiple times before a reseed occurs, then
> the result of the previous call is overwritten.
> 
> Reseeding the 'DRBG' whenever the user calls 'RAND_add()' does not
> seem a good solution. It would be too expensive, in particular if
> system entropy is pulled for reseeding. Of course it is possible to
> fix this issue, but the DRBG provides for a much simpler solution: it
> lets the consumer contribute to the entropy of the internal state by
> providing additional input. If the user input contains entropy,
> that's fine, if it's "snake oil", no harm. The additional input is
> mixed into the internal state in just the same way as the entropy
> buffer using the 'ctr_df()' derivation function. One might think of
> the 'entropy' input as trusted randomness and 'adin' as untrusted
> randomness.
> 
> For this reason, I would like to see the 'RAND_add()/RAND_bytes()'
> pattern deprecated and the 'RAND_DRBG_generate() with additional
> input' pattern advertised instead.

Deprecation itself would probably have to wait for a 1.2.0 release. We
have a binary/source compatibility guarantee for 1.1.0 which would not
be met for builds using "--api" or "no-deprecated".

Is there a potential security vulnerability here? Applications using the
"old" APIs expect RAND_add() to behave in a particular way. If we have
silently changed this behaviour in 1.1.1 are they exposed?

Matt