>> 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. > > That’s my point. API decisions live forever.
Point well taken. Nonetheless…
> Suppose we move around the DRBG’s so that they are per-thread, or
> per-SSL_CTX or per-SSL object? Will that API still work? Or will we
> need a A “RAND_ex_ex” function?
The *API* probably still would work. The *implementation* of it (which is
supposed to stay under the hood) may need to change.
Offhand, I don’t see why the user-level API call would have to be different
depending on whether the relevant DRBG is thread-local, or SSL-object-local.
The only difficulty would be if you want to have *both*…
But my point is – this (“reseeding assistant”) is a needed capability. So it
should be available to the users rather sooner than later…
> We don’t have even consensus on when and how to reseed.
Luckily, for the interface(s) I’m asking for it’s simple – reseed upon explicit
request. ;-)
I understand the concerns for the reseeding in general.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
