JDK-8261433 : Better pkcs11 performance for libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 8,11,17,21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-02-09
  • Updated: 2024-05-21
  • Resolved: 2024-05-13
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 22 JDK 23
22.0.2Fixed 23 b23Fixed
Related Reports
Relates :  
Relates :  
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. 

/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/jdk22u/pull/203 Date: 2024-05-14 10:53:39 +0000

Changeset: 7c2c24fc Author: Prajwal Kumaraswamy <pkumaraswamy@openjdk.org> Committer: Sean Coffey <coffeys@openjdk.org> Date: 2024-05-13 16:10:45 +0000 URL: https://git.openjdk.org/jdk/commit/7c2c24fc0511b36132952c96be46eea5904a53c5

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18425 Date: 2024-03-21 09:23:43 +0000

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.

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

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. */

Investigate if we can detect the Solaris OS instead and always opt to try CK_GCM_PARAMS first.