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

[Blumenthal, Uri - 0553 - MITLL]

On 8/29/17, 11:33, "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:
    
        Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? 
    
 >   From your use-case:  you want to add entropy into a specific DRBG. 

Yes.

  >  You want to push it, as opposed to the DRBG “pull when needed” model.  

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.

Would you agree? Besides possible but probably negligible performance difference – why would you ever want to delay mixing the received “additional input” in?

  >  That’s an additional API.  

I wouldn’t call it “additional”. It may be a change from the current behavior – but I think everybody would welcome such a change. IMHO it can only help, never hurt.

   >  Also from your use-case: you want to specify which DRBG instance gets that entropy. 

Yeah, but that probably isn’t a part of the API that DRBG “object” exposes. 

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

Another “API” is how to tell this specific DRBG instance what exactly I want from it now. E.g., mix more randomness that I provide into its state, give me some random bits, whatever. This part probably can stay close to what it currently is. I think 90A would be satisfied with 3-4 interface calls here…

   >   If we move to a pair per thread, as opposed to one per SSL and two in the global space, how do we make sure that API still works and does the right thing.

Yeah. That’s the “other” part of the API. I think the two API “groups” are pretty (completely?) orthogonal – independent from each other.
    
   >    Does that makes sense, and does it answer your question?
    
 Yeah… What do you think of my reasoning above?

-------------- 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/c5886179/attachment.bin>