FIPS provider too conservative with legacy checks?
Dr Paul Dale
pauli at openssl.org
Mon Jun 12 23:26:52 UTC 2023
This does look like a bug in the FIPS checking.
Unfortunately, any fix will take a long time to make it into a validated
provider and there isn't a way to set the FIPS parameters apart from
during initialisation (there really ought to be one).
The best suggestion I can think of is to have a second library context
with either the default or a non security checking FIPS provider loaded
for verification. Not ideal.
I've raised an issue (#21185
<https://github.com/openssl/openssl/issues/21185>) for this. Even once
it is fixed, I cannot say how long until it makes it way into a
On 10/6/23 04:27, Thomas Dwyer III wrote:
> Our organization signs image artifacts with 2048-bit DSA keys before
> releasing them to the field. Some of these signatures fail to verify
> when using the OpenSSL 3.0 FIPS provider. It turns out that while most
> of our signing keys are (L,N)=(2048,256), two early keys created long
> ago are (2048,160) and the signatures that fail to verify were created
> with these keys. Disabling security checks in the configuration file
> resolves this but I'd prefer not do that and inadvertently let
> something else non-compliant go undetected.
> I discovered this code in providers/common/securitycheck.c:
> * For Digital signature verification DSA keys with < 112 bits of
> * security strength (i.e L < 2048 bits), are still allowed
> for legacy
> * use. The bounds given in SP800 131Ar2 - Table 2 are
> * (512 <= L < 2048 and 160 <= N < 224)
> if (!sign && L < 2048)
> return (L >= 512 && N >= 160 && N < 224);
> I am by no means an expert in cryptography but this logic does not
> seem to match my interpretation of the spec which for legacy use allows:
> ((512 <= L < 2048) or (160 <= N < 224))
> with "or" being the operative word here. OpenSSL is making this an
> "and" condition. Doesn't 800-131Ar2 allow (2048,160) when verifying a
> DSA signature, or am I misreading the spec?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users