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
>
