Re: RAND, FIPS and providers
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 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 >>
Re: RAND, FIPS and providers
FWIW, I agree with Matt's points.
Re: RAND, FIPS and providers
On 24/09/2019 10:17, Matthias St. Pierre wrote: > > On 24.09.19 10:58, Matthias St. Pierre wrote: >> It would also make sense to make the entropy sources themselves fetchable and >> configurable. This would enable us to >> >> - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) > > This concept would also enable us to ensure that FIPS DRBGs can only seed from > FIPS entropy sources, without having to > hardcode the list of approved entropy sources. It's not quite as simple as that. Although allowed by FIPS standards, we made the simplifying assumption that our FIPS module would never fetch or use algorithms external to its own boundary. This is physically not possible in the FIPS module as it stands today. Matt
Re: RAND, FIPS and providers
On 24.09.19 10:58, Matthias St. Pierre wrote: It would also make sense to make the entropy sources themselves fetchable and configurable. This would enable us to - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) This concept would also enable us to ensure that FIPS DRBGs can only seed from FIPS entropy sources, without having to hardcode the list of approved entropy sources. Matthias
Re: RAND, FIPS and providers
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 It would also make sense to make the entropy sources themselves fetchable and configurable. This would enable us to - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) - make the entropy search policy configurable via config file (search order, blocking vs. non-blocking, ...) and it would also enable third party providers to plug in their (FIPS certified) hardware modules as entropy sources. In this context it might help to revisit Pauli's long standing and still unresolved issue #4394: - Multiple entropy source handling - https://github.com/openssl/openssl/issues/4394 Matthias
Re: RAND, FIPS and providers
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 >
