Re: Plea for a new public OpenSSL RNG API

>> 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