[15] RFR 8172680: Support SHA-3 based Hmac algorithms

Valerie Peng valerie.peng at oracle.com
Fri Apr 3 21:32:37 UTC 2020


Hi Mike,

We can update SunPKCS11 provider when the PKCS#11 official header files 
are updated with SHA3 and Hmac w/ SHA3.

I agree with you on the ideal case is to have no lagging in JCA and the 
SunPKCS11 provider.

The main reason for the lagging is that we need to test and make sure 
the added functionality works. I checked NSS which is what existing 
PKCS11 regression tests use and it does not have any SHA3 support. Do 
you know other PKCS11 vendors which supports SHA3 and Hmac w/ SHA3? If 
there are many, it'll help me justifying this when the official headers 
are not updated yet.

I am not sure if I understand your suggestion of PKCS11 specific 
mechanism naming convention. Is it about duplicating the pending SHA3 
mechanism definitions in SunPKCS11 provider? It's trivial to add the 
SHA3 related mechanism definitions to SunPKCS11 provider, but the 
convention is to add things only after they are official as it may be 
hard to change due to backward compatibility concern.

Thanks & hope you get enough sleep during this difficult time...

Valerie

On 3/31/2020 10:15 AM, Michael StJohns wrote:
> Sorry - this one got past me.
>
> For PKCS11 - the assignment of mechanism numbers can happen at any 
> time and doesn't necessarily result in a new version of the 
> specification.  In this case, the API won't change, so there's no 
> reason - since the mechanism numbers have been assigned since last May 
> at least - to wait for V3.  Among other things, I would expect that 
> various vendors have already implemented these in their 2.xx 
> implementations.
>
> One of the reasons I ended up using the SunPKCS11 wrapper classes 
> directly quite a while ago was that the PKCS11 spec hadn't been 
> updated, but that my PKCS11 provider was supplying various EC 
> mechanisms that I needed. Ideally, the JCA and SunPKCS11 provider 
> support should *precede* any given underlying PKCS11 device support, 
> not trail it by 6-12 months.
>
> The assignment of mechanism numbers is exactly equivalent to the 
> assignment of TLS cipher suite numbers - the underlying protocol 
> doesn't change, so this is mostly a change to the mapping tables and 
> enclosed classes.
>
> In any event, any given PKCS11 implementation may or may not support 
> any given set of mechanisms - the provider really ought to be calling 
> C_GetMechanismList() and using that as the list of supported JNA 
> mechanisms.
>
> Sorry - I'm dealing with a bit of lack of sleep here so I may be 
> babbling, but I'm wondering if it might not be a bad idea to add some 
> sort of PKCS11 specific mechanism naming convention to allow for the 
> lag/lead problem? E.g   PKCS11_DIGEST_000002B0 would be PKCS11's 
> CKM_SHA3_256 hashing function given
>
>> #define CKM_SHA3_2560x000002B0
>>
> Just a thought.
>
> Thanks - Mike
>
>
> On 3/19/2020 5:27 PM, Valerie Peng wrote:
>> Hi Mike,
>>
>> Thanks for heads up. From what I can gather, SHA3 inclusion is part 
>> of PKCS#11 v3. Is this the next release which you are referring to? 
>> Or will there be an update to v2.40? Is there any schedule info for 
>> these update/release do you know?
>>
>> Following the convention, we normally don't add something which the 
>> underlying library has no support yet. With the new 6-month JDK 
>> release cycle, it's much faster for the added functionality to be 
>> available. So, I'd still prefer to update SunPKCS11 provider with 
>> SHA-3 once they are officially included.
>>
>> Valerie
>>
>> On 3/18/2020 4:07 PM, Michael StJohns wrote:
>>> On 3/18/2020 6:57 PM, Valerie Peng wrote:
>>>>
>>>> Anyone has time to help review this straight forward RFE? It's to 
>>>> add SHA-3 support to Hmac.
>>>>
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/
>>>>
>>>> Mach5 run is clean.
>>>>
>>>> Thanks,
>>>> Valerie
>>>
>>> Valerie -
>>>
>>> I know the RFE says no PKCS11 because 2.40 doesn't include those 
>>> items, but OASIS PKCS11 has proposed  SHA3 identifiers at 
>>> https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result 
>>> - maybe reach out and ask if these have been allocated pending the 
>>> next release?
>>>
>>> Mike
>>>
>>>
>>> #define CKM_SHA3_256              0x000002b0UL
>>>  #define CKM_SHA3_256_HMAC         0x000002b1UL
>>>  #define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL
>>>  #define CKM_SHA3_224              0x000002b5UL
>>>  #define CKM_SHA3_224_HMAC         0x000002b6UL
>>>  #define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL
>>>  #define CKM_SHA3_384              0x000002c0UL
>>>  #define CKM_SHA3_384_HMAC         0x000002c1UL
>>>  #define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL
>>>  #define CKM_SHA3_512              0x000002d0UL
>>>  #define CKM_SHA3_512_HMAC         0x000002d1UL
>>>  #define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200403/b96b0619/attachment.htm>


More information about the security-dev mailing list