Bug ID: JDK-8271566 DSA signature length value is not accurate in P11Signature

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17	JDK 18	JDK 19
17.0.10Fixed	18 b27Fixed	19Fixed

In DSA signatures, the length of 'q' (CKA_SUBPRIME) does not derive from the length of 'p' (CKA_PRIME). Even when some tuples are common (as seen in OpenJDK for example [1]), they are an implementation-dependent assumption. I've seen for example 'p' values of 2048 with 'q' of 256, instead of 2048 with 224.

The length of a DSA signature is the length of 'q' * 2. Thus, this [2] and this [3] does not look good to me (in the latter case assuming a CKM_DSA_SHA1 or similar DSA-based mechanism). Even when we can say 'larger does not harm', here [4] it does not hold true if we use a 256 'q'. Furthermore, with an accurate value we can avoid passing '0' here [5] and having 2 C_SignFinal native calls with 1 extra buffer allocation in the heap.

In my view, we should use an accurate value for the signature length in DSA, and we already have an API to get it from the actual key [6] (which translates to a PKCS#11 call to get the CKA_SUBPRIME attribute from a key). This API works even when the key is CKA_SENSITIVE = true (the value retrieved is not sensitive).

--
[1] - https://github.com/openjdk/jdk/blob/a066c7bed0f9aa45fb9384f75ae84943548cd859/src/java.base/share/classes/sun/security/provider/ParameterCache.java#L89
[2] - https://github.com/openjdk/jdk/blob/a066c7bed0f9aa45fb9384f75ae84943548cd859/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L301
[3] - https://github.com/openjdk/jdk/blob/a066c7bed0f9aa45fb9384f75ae84943548cd859/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L303
[4] - https://github.com/openjdk/jdk/blob/a066c7bed0f9aa45fb9384f75ae84943548cd859/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L827
[5] - https://github.com/openjdk/jdk/blob/a066c7bed0f9aa45fb9384f75ae84943548cd859/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L621
[6] - https://github.com/openjdk/jdk/blob/a066c7bed0f9aa45fb9384f75ae84943548cd859/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L773

Fix request (17u): I would like to backport the fix for this bug to jdk17u, as this release is affected. The main line patch does not apply cleanly but a proposal has been reviewed here [1]. This backport has low risk. -- [1] - https://github.com/openjdk/jdk17u-dev/pull/1982

27-11-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1982 Date: 2023-11-21 22:37:40 +0000

21-11-2023

Changeset: ea8d3c92 Author: Martin Balao <mbalao@openjdk.org> Date: 2021-12-06 20:31:55 +0000 URL: https://git.openjdk.java.net/jdk/commit/ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3

06-12-2021

Relates :	JDK-8336499 - Failure when creating non-CRT RSA private keys in SunPKCS11
Relates :	JDK-8271510 - Failure in P11Signature sign with 2048-bit DSA keys and NSS Software Token (JDK-11)
Relates :	JDK-8325254 - CKA_TOKEN private and secret keys are not necessarily sensitive