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

[Kurt Roeckx]

On Tue, Aug 29, 2017 at 11:31:03AM +0000, Dr. Matthias St. Pierre wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: openssl-dev [mailto:openssl-dev-bounces at openssl.org] Im Auftrag von Matt Caswell
> > Gesendet: Dienstag, 29. August 2017 12:17
> > An: openssl-dev at openssl.org
> > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API
> > 
> > 
> > On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
> > > ...
> > > 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:
> > > ...
> > 
> > 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?
> 
> Don't worry, this issue is new, the global 'rand_bytes' buffer has only been introduced by the DRBG port to master in August. I don't think it's a big deal to fix it. The reason I mentioned it here was to emphasize, that it is really hard to get the different philosophies (push vs. pull) of the two APIs working together correctly. The code was reviewed by several people and nobody noticed it. By the way: the approach using the fixed size global 'rand_bytes' buffer has another issue, which I will try to write down on GitHub within the next days.

I've actually noticed how this works and I have already partially
rewritten it, but I'm still not very happy about it. I think by
RAND_add() should not be called internally. But the question then
is what to do when an application calls RAND_add(), we should be
doing something with the buffer that's given. I think the best way
to deal with it is with the DRBG API is used, RAND_add() is used for
additional data.

We now have 2 global DRBGs, and I think I want to have 1 of them
chain to the other. RAND_add() could then be used for the master.

An other problem with the current implemenation is that the
randomness parameter that's now given to RAND_add() is just
ignored, it assumes it's the same as the length.


Kurt