On 8/29/17, 11:33, "openssl-dev on behalf of Salz, Rich via openssl-dev" 
<openssl-dev-boun...@openssl.org on behalf of openssl-dev@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?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to