Bug ID: JDK-8261433 Better pkcs11 performance for libpkcs11:C_EncryptInit/libpkcs11:C

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 23
23Unresolved

For Ciphers running through the CKM_AES_GCM SunPKCS11 mechanism - two types of CK_GCM_PARAMS struct are used in order to deal with interoperability issues introduced with PKCS#11 v2.40. (JDK-8080462/JDK-8229243)

CK_GCM_PARAMS_NO_IVBITS is attempted first. If that fails, then CK_GCM_PARAMS is attempted. 

This is a performance hit since only the 2nd struct is successful in both NSS and Solaris libpkcs11 where PKCS#11 spec version is 2.40 and above. 

e.g:
/2:     lseek(15, 0x0001B390, SEEK_SET)                 = 111504
/2:     read(15, "85 R m S12 Q18 =97B7 ] p".., 579)     = 579
/2@2:   -> libpkcs11:C_EncryptInit(0x1005d6770, 0x1007a46a0, 0x1005fa840, 0x0)
/2@2:     -> libucrypto:crypto_encrypt_init(0xffffffff7f2eee08, 0xffffffff7f2eee20, 0x0, 0x1005d68b8)
/2@2:     <- libucrypto:crypto_encrypt_init() = 29
/2@2:   <- libpkcs11:C_EncryptInit() = 113
/2@2:   -> libpkcs11:C_EncryptInit(0x1005d6770, 0x1007a46a0, 0x1005fa840, 0x71)
/2@2:     -> libucrypto:crypto_encrypt_init(0xffffffff7f2eee08, 0xffffffff7f2eee20, 0x0, 0x1005d68b8)
/2@2:     <- libucrypto:crypto_encrypt_init() = 0
/2@2:   <- libpkcs11:C_EncryptInit() = 0

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18425 Date: 2024-03-21 09:23:43 +0000
21-03-2024
I observed that in NSS 3.52 the spec version has been updated to 2.40 and from here on the normative versions of CK_GCM_PARAMS (i.e. with IV bits) are being used. The latest fix can use this spec version to determine which version of struct should be sent.
08-03-2024
The changes to support normative version was made from 3.52 https://nss-crypto.org/reference/security/nss/legacy/nss_releases/nss_3.52_release_notes/index.html#mozilla-projects-nss-nss-3-52-release-notes https://bugzilla.mozilla.org/show_bug.cgi?id=1603628
08-03-2024
the history of this CK_GCM_PARAMS struct is a bit of a mess. NSS have tried to address it view this commit from 2020: https://github.com/nss-dev/nss/commit/ba931199b9 Some history in lib/softoken/pkcs11c.c : /* * Due to a mismatch between the documentation and the header * file, two different definitions for CK_GCM_PARAMS exist. * The header file is normative according to Oasis, but NSS used * the documentation. In PKCS #11 v3.0, this was reconciled in * favor of the header file definition. To maintain binary * compatibility, NSS now defines CK_GCM_PARAMS_V3 as the official * version v3 (V2.4 header file) and CK_NSS_GCM_PARAMS as the * legacy (V2.4 documentation, NSS version). CK_GCM_PARAMS * is defined as CK_GCM_PARAMS_V3 if NSS_PKCS11_2_0_COMPAT is not * defined and CK_NSS_GCM_PARAMS if it is. Internally * softoken continues to use the legacy version. The code below * automatically detects which parameter was passed in and * converts CK_GCM_PARAMS_V3 to the CK_NSS_GCM_PARAMS (legacy * version) on the fly. NSS proper will eventually start * using the CK_GCM_PARAMS_V3 version and fall back to the * CK_NSS_GCM_PARAMS if the CK_GCM_PARAMS_V3 version fails with * CKR_MECHANISM_PARAM_INVALID. */
19-12-2022
Investigate if we can detect the Solaris OS instead and always opt to try CK_GCM_PARAMS first.
09-02-2021

Relates :	JDK-8229243 - SunPKCS11-Solaris provider tests failing on Solaris 11.4
Relates :	JDK-8080462 - Update SunPKCS11 provider with PKCS11 v2.40 support