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

Dr. Matthias St. Pierre Matthias.St.Pierre at ncp-e.com
Tue Aug 29 11:31:03 UTC 2017


> -----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.

Matthias
 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170829/c140edee/attachment.bin>


More information about the openssl-dev mailing list