Re: Work on a new RNG for OpenSSL

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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev