Hi Valerie -
In line
On 4/3/2020 5:32 PM, Valerie Peng wrote:
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've got an include file from Utimaco dated 27 March 2017 that includes
the SHA3 assignments from PKCS11 - and their collateral says they
implement SHA3 (this is all of the message digest, hmac and signature
mechanisms, and key derivation mechanisms specified for PKCS11 3.0.
Safenet ProtectServer has it
https://data-protection-updates.gemalto.com/2018/04/27/product-release-safenet-protecttoolkit-5-6/
I can't find anything that says nCipher has it.
That's two out of three of the big ones.
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.
Something like MessageDigest.getInstance ("SHA3_256", pkcs11provider)
ends up mapping to an underlying call "CK_MECHANISM m = new CK_MECHANISM
(CKM_SHA3_256);" where CKM_SHA3_256 is "public static long CKM_SHA3_256
= 0x000002b0L;"
There are at times a number of proprietary or provider specific
algorithms that the underlying PKCS11 dll might support, but for which
the Java PKCS11 provider doesn't have the string (name) to mechanism
number mapping, but for which the API is the same as for any other
algorithm of its class.
For example, the Utimaco PKCS11 definitions include
#define CKM_DES3_RETAIL_MAC 0x80000135 // Retail-MAC with
0-Padding
Which is unlikely to be part of any PKCS11 standard, but could be
accessed by
Mac.getInstance ("PKCS11_MAC_16_80000135", pkcs11provider); // 16 is the
mac length.
So this is an escape mechanism to permit access to provider extensions
without having to reflect them back into the Java PKCS11 provider.
(When support for EC algorithms were being kept from various software -
including NSS - due to nervousness about patent claims, I ended up using
the PKCS11 wrapper classes directly specifically because I couldn't do
an ECDSA via the PKCS11 provider. That hasn't been the case for a
while, but it's always bothered me that the JCA got in the way of the
underlying provider.)
I don't know that is doable given the current architecture (which
usually requires an OID for a mechanism to register it for SunPKCS11),
but something to think about.
Thanks & hope you get enough sleep during this difficult time...
*laugh* I'm doing better thanks. I wrenched something in my shoulder
and it kept me awake or woke me up when I was sleeping. Much better now.
Thanks! Mike
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
