JDK-8255407 : Support key generation for HMAC mechanisms
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2020-10-26
  • Updated: 2023-10-23
  • Resolved: 2023-10-23
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 16
Related Reports
CSR :  
Duplicate :  
Duplicate :  
SunPKCS11 provider "translates" the provided SecretKey for Hmac crypto service, i.e. takes a java SecretKey object, extracts its key bytes and convert it into a CKK_GENERIC_SECRET key.

For HSM or scenarios where the key bytes need to be from the underlying PKCS11 library, it requires SunPKCS11 provider to support the CKM_GENERIC_SECRET_KEY_GEN mechanism and provide a KeyGenerator crypto service.


Given the release time frame, will cover this RFE as part of changes for 8242332 "Add SHA3 support to SunPKCS11 provider" (tracked at https://bugs.openjdk.java.net/browse/JDK-8242332 ). Both changes depend on PKCS#11 v3.0 header file update and requires CSR and are somewhat intertwined thus can't go in parallel. One covers SHA3 digests, signature, mac. The other covers key generation for mac. The intertwined part is key generation for mac with SHA3 digests. Will close this as duplicate of JDK-8242332.

PKCS#11 v3.0 sec2.8.3: ------------------------------------- 2.8.3 Generic secret key generation The generic secret key generation mechanism, denoted CKM_GENERIC_SECRET_KEY_GEN, is used to generate generic secret keys. The generated keys take on any attributes provided in the template passed to the C_GenerateKey call, and the CKA_VALUE_LEN attribute specifies the length of the key to be generated. It does not have a parameter. The template supplied must specify a value for the CKA_VALUE_LEN attribute. If the template specifies an object type and a class, they must have the following values: CK_OBJECT_CLASS = CKO_SECRET_KEY; CK_KEY_TYPE = CKK_GENERIC_SECRET; For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of key sizes, in bits. ------------------------------------- However, NSS 3.55 has: Mechanism CKM_GENERIC_SECRET_KEY_GEN: ulMinKeySize: 1 ulMaxKeySize: 32 flags: 32768 = CKF_GENERATE Thus, it seems that NSS is reporting the min/max key size in bytes. Even so, upper end of 32 byte is only 256 bits. Seems a bit small if we were to use the same default key size as SunJCE provider, i.e. the digest output length. For example, HmacSHA512 uses 512 as the default key size if not initialized explicitly.