On 8/29/17, 15:22, "openssl-dev on behalf of Salz, Rich via openssl-dev"
<openssl-dev-boun...@openssl.org on behalf of openssl-dev@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. ;-)
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
