➢ 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.
➢ 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.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
