FIPS provider too conservative with legacy checks?

[Dr Paul Dale]

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 
validated provider.


Pauli

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?
>
>
> Thanks,
> Tom.III
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230613/fa5614b4/attachment.htm>