[openssl-dev] Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL uri at ll.mit.edu
Thu Aug 24 20:33:11 UTC 2017


>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170824/49b7fa3f/attachment-0001.bin>


More information about the openssl-dev mailing list