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

[Michael StJohns]

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/20200331/ef0a4bfe/attachment.htm>