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) 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
