RAND, FIPS and providers

[Dr Paul Dale]

Matt, thanks for the clarification.  I’ve looked at the DRBG setup code dozens of times and it never clicked.

It seems we’re down to making the DRBGs and, perhaps, the seed source available using fetch.
That doesn’t seem anything like as difficult.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 24 Sep 2019, at 6:32 pm, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
> 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
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190925/89572d88/attachment.html>