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
