On 8/29/17, 11:33, "openssl-dev on behalf of Salz, Rich via openssl-dev" <[email protected] on behalf of [email protected]> 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?
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
