RFR: 8261433: Better pkcs11 performance for libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
Valerie Peng
valeriep at openjdk.org
Mon Mar 25 21:08:24 UTC 2024
On Mon, 25 Mar 2024 06:34:53 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:
> > Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,
> >
> > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead.
> > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.
>
> If PKCS11 spec version is less than 2.40, we are retaining the same logic as it exists today. If we make the above changes then there will be a crash in NSS version 3.51 and below where PKCS11 2.20 spec is used.
>
> However, I can optimze the code by introducing new boolean variable in C_DecryptInit and C_EncryptInit to indicate if we need to send normative struct. If so, I'll add a goto statement to updateGCM params. I did not do this initially because in 11u and above I have seen goto being removed.
Yes, it's better to add one boolean argument and just have one EncryptInit/DecryptInit() method. As times goes by, I'd expect old NSS library usage to die out and we should optimize the flow toward normative version.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2018913831
More information about the security-dev
mailing list