>> I personally see no harm if these RNG objects are made available to >> applications that need/use them > > But decisions like this live forever. It is therefore VERY important to > spend time thinking about what > becomes part of the public API and what remains hidden so that we can change > things later when we > have a better understanding. No argument here, especially since I can’t claim to understand all the implications of exposing RNG (yet ;). But it is clear that at least some applications need to work with an RNG more closely than others, and would want more control over its behavior.
> This concept is new to OpenSSL :)
:-) :-)
> But we just put out a 1.1.0 release that made things opaque, so it’s more
> fresh in the minds of at
> least some of the dev team.
In general, making things opaque is a good idea, RNG included. But:
> Personally, since DRBG is new in 1.1.1 I would be quite happy if we didn’t
> expose anything public
> until the release after that.
Even opaque objects usually have some public interface. I think exposing
RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an
acceptable “live forever” API.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
