>> I *don’t want* OpenSSL to make *any* estimation of the amount of provided
>> entropy. All I want it to do is to mix these bits into the RNG state. It’s
>> *my* business how much entropy I’m providing – but I don’t want OpenSSL to
>> make any decision regarding pull from other entropy sources based on my
>> input.
>>
>> Does it sound reasonable? (He, it does to me ;)
>
> But that is not the API that RAND_add() provides.
Yes, I realize that, sort of. But nonetheless, that’s the interface/behavior
that I think an RNG should offer.
> It's a push not
> a pull API. With the DRBG you can do this, assuming using it's an
> extraction / derivative function.
Not sure I understand. But “…you can do this…” sounds encouraging. ;-)
> One of the suggestions I did before is to have RAND_poll_ex() take
> a parameter about how much randomness is needed, but I think it's
> also a wrong API and I'm thinking about removing it.
There are two aspects:
The RNG itself keeping track of how much entropy it has in its pool/state, and
thus when to pull its (standard) entropy sources for more (and specifically for
how much more). I don’t want to interfere with this part.
The user-visible/accessible interface to RNG that allows:
Forcing the “reseed”, making the RNG to to its sources for “fresh” entropy
regardless of what’s up with its internal state;
Telling the RNG to immediately mix the given bits into its state, without
adjusting its count of available/present entropy.
>> If I had my way, you’d assume that every bit contains 0 bits of entropy, but
>> mix it in regardless because that’s what the user is asking you to do.
>
> Which is why I suggested we use this for the additional data.
Yes, precisely. That’s exactly what I plan to use this interface for - mixing
in additional data. NIST 800-90A Rev1 has “additional input” only as part of
Reseed() or Generate(). I can live with that (i.e., with the fact that right
before my randomness is mixed in, the entire state s replaced). Though ideally
we’d have “RAND_add_ex()” or such that does not require replacing the entire
state with fresh data from entropy source (because if that capability is
needed, it is easy to emulate by issuing two calls: “Reseed(); Add_ex();"
> But
> I think that as long as we have both APIs we might actually need
> it for the entropy input. If there is no other way to add
> randomness, RAND_add() is our current documented way to add it,
> and it will need to keep working.
It’s perfectly OK for me if RAND_add() keeps working. What I’d like to change
about it is exactly when the mixing occurs. I’d like the state updated
immediately upon RAND_add(), not when the RNG in question decides that it needs
to replenish its entropy supply. I think this change would only improve
security of applications that use it.
TNX!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
