RAND, FIPS and providers

[Matt Caswell]

On 24/09/2019 01:17, Dr Paul Dale wrote:
> This started in #9954, the topic of RAND being used by the legacy provider came up (in the context of DES).  The abridged version is:
> 
> * @levitte suggested the possibility of making RAND detachable.
> * I noted that this was desirable and in fact necessary for FIPS.
> * @mattcaswell added that the DRBGs and seeding is available inside the FIPS provider.
> 
> 
> That the FIPS provider includes a copy of the relevant RAND files, means it can satisfy internal requests for random numbers.
> However, external entities (TLS stack, user applications) won’t git FIPS approved random numbers.
> 
> I can’t see currently an alternative to making the RAND functionality fetchable.

I think making RAND fetchable is highly desirable and should be done (I had
always assumed we would do this).

>  I also suspect it will need to be per library context which might interfere with the per thread DRBGs we’re using.

I see no problems here. The RAND code is already library context aware. You get
per thread DRBGs for each OPENSSL_CTX. For example calling
OPENSSL_CTX_get0_private_drbg() will get you the private DRBG for the current
thread in the specified OPENSSL_CTX. RAND_DRBG_get0_private() does the same
thing for the default OPENSSL_CTX.


> As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don’t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider).

I had always assumed we would fetch DRBG instances.

Matt

> 
> 
> Thoughts or input anyone?
> 
> 
> Pauli
>