[14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4"
Valerie Peng
valerie.peng at oracle.com
Thu Sep 19 01:01:53 UTC 2019
Ping?
Can someone help take a look?
Thanks,
Valerie
On 8/15/2019 4:49 PM, Valerie Peng wrote:
>
> Anyone has time to help review this fix? PKCS#11 v2.40 has
> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec
> (sec 2..12.3) has:
>
> typedef struct CK_GCM_PARAMS {
> CK_BYTE_PTR pIv;
> CK_ULONG ulIvLen;
> CK_BYTE_PTR pAAD;
> CK_ULONG ulAADLen;
> CK_ULONG ulTagBits;
> } CK_GCM_PARAMS;
>
> However, the header file pkcs11t.h has an extra "ulIvBits" field:
>
> typedef struct CK_GCM_PARAMS {
> CK_BYTE_PTR pIv;
> CK_ULONG ulIvLen;
> * CK_ULONG ulIvBits;*
> CK_BYTE_PTR pAAD;
> CK_ULONG ulAADLen;
> CK_ULONG ulTagBits;
> } CK_GCM_PARAMS;
>
> Some vendors such OpenHSM2 and Solaris go with the header file while
> some vendor such as NSS go with the mech spec. Current SunPKCS11
> provider impl works with NSS but not with other vendors whose
> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing
> results, OpenHSM2 and Solaris error out at init time when the
> parameter length does not have their expected value. Thus, one way to
> workaround this inconsistency is to re-try with a different structure
> for AES GCM when the init failed. In addition, given the parameters
> contains Iv and AAD which some vendor may use during subsequent
> enc/dec operations, I changed to use the same model as RSASSA-PSS to
> defer the freeing after the enc/dec operation is finished. Verified
> the changes on Solaris 11.4 against existing GCM regression tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243
>
> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/
>
> Thanks,
> Valerie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190918/95f733f5/attachment.htm>
More information about the security-dev
mailing list