PRNG not available when multiple providers are configured?
matt at openssl.org
Wed Nov 4 09:10:58 UTC 2020
Ah! I had completely forgotten about this option.
On 03/11/2020 21:34, Dr Paul Dale wrote:
> | config_diagnostics = 1|
> At the same level as the openssl_conf line should produce more output.
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>> On 4 Nov 2020, at 4:41 am, Thomas Dwyer III <tomiii at tomiii.com
>> <mailto:tomiii at tomiii.com>> wrote:
>> On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell <matt at openssl.org
>> <mailto:matt at openssl.org>> wrote:
>> On 03/11/2020 00:55, Thomas Dwyer III wrote:
>> > I'm having trouble getting RAND_status() to return 1 when my
>> > has both the default provider and the fips provider configured
>> at the
>> > same time:
>> > openssl_conf = openssl_init
>> > [openssl_init]
>> > providers = provider_sect
>> > [provider_sect]
>> > default = default_sect
>> > fips = fips_sect
>> > [default_sect]
>> > activate = 1
>> > .include /conf/openssl/fips.cnf
>> > If I remove either default or fips from [provider_sect] then
>> > RAND_status() returns 1. If I leave them both specified there,
>> > RAND_status() always returns 0. Is this the expected behavior or
>> am I
>> > doing something wrong? I understand that I must specify
>> properties when
>> > fetching algorithms in order to get deterministic behavior with
>> > providers loaded. Is there an analogous API for the PRNG that I'm
>> > overlooking?
>> > Interestingly, setting activate=0 for either provider is not
>> > to work around this issue.
>> I tested this out and was able to replicate your behaviour.
>> The reasons are a little complicated (see below) but the TL;DR summary
>> is that there is an error in your config file. The ".include" line
>> should specify a config file relative to OPENSSLDIR (or
>> OPENSSL_CONF_INCLUDE if it is set). It cannot be an absolute path, and
>> hence fips.cnf is not being found.
>> This explanation does not match my observations. strace clearly shows
>> my fips.cnf getting opened and read when my openssl.cnf has an
>> absolute path. Likewise, strace shows stat64("fips.cnf", ...) failing
>> (and thus no subsequent open() call) when I use a relative path.
>> Furthermore, the documentation
>> at https://www.openssl.org/docs/manmaster/man5/config.html
>> <https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man5/config.html__;!!GqivPVa7Brio!INBlyBEyGaYipDhT7pzBHbqNWwT_X9g1JEID9D5HZmFB-cmNRMWGUEoRqaZMNvs$> says
>> this should be an absolute path.*
>> That said, see below..
>> I've seen this error a few times now so I'm thinking that we should
>> perhaps allow absolute paths. I'm not sure what the reason for
>> disallowing them was.
>> The reason it works if you comment out the "default" line is because
>> that means the only provider left is the FIPS one. But the config line
>> for that is faulty and therefore activating it fails. Ultimately
>> we have
>> not succesfully activated any provider. When you call RAND_status() it
>> will attempt to fetch the RAND implementation and find that no
>> have been activated. In this case we fallback and automatically
>> the default provider. Hence you end up with RAND_status() still
>> If you comment out the "fips" line then it works because it doesn't
>> attempt to do anything with the fips provider, successfully activates
>> the default provider, and hence RAND_status() works as expected.
>> If you have both lines in the config file then it first successfully
>> activates the default provider. It next attempts to activate the fips
>> provider and fails. The way the config code works is that if any
>> of the
>> configured providers fail to activate then it backs out and
>> all of them. At this point we're in a situation where a provider has
>> been successfully activated and then deactivated again. The fallback
>> activation of the default provider only kicks in if you've not
>> to activate any providers by the time you first need one.
>> Therefore the
>> default provider doesn't activate as a fallback either. Ultimately you
>> end up with no active providers and RAND_status() fails.
>> Ah ha! This explanation makes sense to me and indeed pointed me at the
>> real problem. I had recompiled OpenSSL but I forgot to update the hmac
>> in fips.cnf via fipsinstall. So yes, the fips provider was failing to
>> activate because of that. As soon I fixed the hmac RAND_status()
>> started working for me. So THANKS for that! :-)
>> We really should have a way of getting more verbose output in the
>> of config issues like this.
More information about the openssl-users