FIPS provider too conservative with legacy checks?
Thomas Dwyer III
thomas.dwyer at oracle.com
Fri Jun 9 18:27:21 UTC 2023
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
* 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