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

Tue Aug 29 19:55:14 UTC 2017

On 8/29/17, 15:22, "openssl-dev on behalf of Salz, Rich via openssl-dev" <openssl-dev-bounces at openssl.org on behalf of openssl-dev at openssl.org> wrote:
    ➢ I’d like to suggest that any approach other than “immediately mix the received randomness into the RNG state” is bad. If a user does RAND_add() now, as opposed to 100 source code lines before, there may be a reason for that.

>    I think the only way to do that in the DRBG model is to treat it as “additional input” and
>    do a generate call.  I think that would achieve the same effect, but it wouldn’t delay any
>    possible seeding of randomness that the DRBG itself needs at some point.

That is OK if the application manually invokes generate(). If it’s the RNG responsible for feeding key generators (who would call generate() transparently to user), then the only way I see is DRBG reseed(). Even though it implies a complete state replacement.

AFAIK, there are three cases when randomness source(s) is pulled:

a. At the instantiation time (page 29 of NIST SP 800-90A Rev1 draft).
b. Upon reseed call (pages 30-31).
c. During generation call(pages 32-36).

“Additional input” (i.e., what I’m after :) is present in two of the above: reseeding, and generation (pages 19 and 23).

The draft is very clear that this “additional input” shall not be counted towards the “official” entropy (aka calculations when to pull the “official” entropy sources). Which suits my purposes just fine. ;-)

I realize that reseed() not only mixes my “additional input” but also replaces the entire state. NIST does not specify interface to “just” mix the “additional input” into the state without replacing the whole state with some fresh entropy by calling Get_entropy_input(). Maybe we can provide such a function call (that’s what I think RAND_add() is supposed to do), but I’m not certain here… 

Wonder what others think? Do you believe that if you want to mix some more randomness into the RNG state to improve upon less-than-perfect entropy sources, you must also replace the entire state with the fresh pull from those sources? Or is it OK to just “spice” the current state with “additional input”?

Note that regardless of the answer to the above, IMHO reseed() should be able to take “additional input”. (NIST considers it optional, but sensitive/critical applications don’t. ;)

    ➢    One “API” is how to get a reference/pointer/instance/whatever to the DRBG object responsible for the operation I’m now concerned with,
➢  and that I want to influence/improve. This would probably differ between per-SSL DRBG and per-thread DRBG, etc. I haven’t even
➢  thought about this part of the API (and I’m sure others on the team have more experience and understanding of the OpenSSL code
➢  to do it better than I would anyway).

 >     Yes, it is separate.  But I want to make sure that if we are doing a comprehensive RAND overhaul that this is included in the requirements.

Yes, it should be included. But don’t let it stop us from defining/reviewing the “clearer” part of the API.  ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170829/a32de336/attachment-0001.bin>