Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Hi Mike,
Thanks much for the comments and info~
I filed JDK-8242332 "Add SHA3 support to SunPKCS11 provider"
(https://bugs.openjdk.java.net/browse/JDK-8242332) to track the SHA3
support for PKCS11 provider. I think it's easier/cleaner to handle it
separately and makes it more visible.
As for supporting vendor-specific mechanisms, that is probably lower
priority than supporting standard SHA3 mechanisms.
It's true that the APIs are the same if the mechanisms are of the same
type. It can probably be achieved by enhancing PKCS11 provider
configuration if such support is needed. But so far, no one has
requested about it.
Regards,
Valerie
On 4/3/2020 5:29 PM, Michael StJohns wrote:
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 = 0x02b0L;"
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 0x8135 // 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_8135", 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Thanks for the heads up. It should be straightforward to handle/merge. Valerie On 4/6/2020 12:17 AM, Weijun Wang wrote: FYI: I'm about to work on CMS support for RSASSA-PSS and EdDSA, and would like to move all signature-related methods (everyone starting from makeSigAlg) from AlgorithmId.java to SingatureUtil.java. Hopefully it will not conflict with your code change. --Max On Mar 21, 2020, at 5:48 PM, Weijun Wang wrote: On Mar 21, 2020, at 2:39 AM, Valerie Peng wrote: As I have started prototyping changes for minimizing the current duplication of oids in various providers and sun.security.x509.AlgorithmId class, I choose to leave AlgorithmId class out for now. Very glad to hear this. No need to touch more on AlgorithmId.java then. Thanks, Max
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
FYI: I'm about to work on CMS support for RSASSA-PSS and EdDSA, and would like to move all signature-related methods (everyone starting from makeSigAlg) from AlgorithmId.java to SingatureUtil.java. Hopefully it will not conflict with your code change. --Max > On Mar 21, 2020, at 5:48 PM, Weijun Wang wrote: > > > >> On Mar 21, 2020, at 2:39 AM, Valerie Peng wrote: >> >> As I have started prototyping changes for minimizing the current duplication >> of oids in various providers and sun.security.x509.AlgorithmId class, I >> choose to leave AlgorithmId class out for now. > > Very glad to hear this. No need to touch more on AlgorithmId.java then. > > Thanks, > Max >
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
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
= 0x02b0L;"
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 0x8135 // 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_8135", 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_02B0 would be PKCS11's
CKM_SHA3_256 hashing function given
#define CKM_SHA3_2560x02B0
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
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_02B0 would be PKCS11's CKM_SHA3_256 hashing function given #define CKM_SHA3_2560x02B0 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 0x02b0UL #define CKM_SHA3_256_HMAC 0x02b1UL #define CKM_SHA3_256_HMAC_GENERAL 0x02b2UL #define CKM_SHA3_224 0x02b5UL #define CKM_SHA3_224_HMAC 0x02b6UL #define CKM_SHA3_224_HMAC_GENERAL 0x02b7UL #define CKM_SHA3_384 0x02c0UL #define CKM_SHA3_384_HMAC 0x02c1UL #define CKM_SHA3_384_HMAC_GENERAL 0x02c2UL #define CKM_SHA3_512 0x02d0UL #define CKM_SHA3_512_HMAC 0x02d1UL #define CKM_SHA3_512_HMAC_GENERAL 0x02d2UL
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
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_02B0 would be PKCS11's CKM_SHA3_256 hashing function given #define CKM_SHA3_2560x02B0 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 0x02b0UL #define CKM_SHA3_256_HMAC 0x02b1UL #define CKM_SHA3_256_HMAC_GENERAL 0x02b2UL #define CKM_SHA3_224 0x02b5UL #define CKM_SHA3_224_HMAC 0x02b6UL #define CKM_SHA3_224_HMAC_GENERAL 0x02b7UL #define CKM_SHA3_384 0x02c0UL #define CKM_SHA3_384_HMAC 0x02c1UL #define CKM_SHA3_384_HMAC_GENERAL 0x02c2UL #define CKM_SHA3_512 0x02d0UL #define CKM_SHA3_512_HMAC 0x02d1UL #define CKM_SHA3_512_HMAC_GENERAL 0x02d2UL
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
> On Mar 21, 2020, at 2:39 AM, Valerie Peng wrote: > > As I have started prototyping changes for minimizing the current duplication > of oids in various providers and sun.security.x509.AlgorithmId class, I > choose to leave AlgorithmId class out for now. Very glad to hear this. No need to touch more on AlgorithmId.java then. Thanks, Max
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Sure, I will do that. Thanks for the review~ Valerie On 3/19/2020 11:08 PM, Jamil Nimeh wrote: The CSR looks straightforward to me. You might mention that these algorithms are Standard Names in the specification section, but it's just a nit. --Jamil On 3/19/2020 3:50 PM, Valerie Peng wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8241325 Please review~ Thanks! Valerie On 3/19/2020 12:54 PM, Valerie Peng wrote: And CSR also. On 3/19/2020 12:53 PM, Valerie Peng wrote: Hi Sean, Yes, thanks for the reminder. I will file the release note and provider doc issue for this. Valerie On 3/19/2020 8:08 AM, Sean Mullan wrote: Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Hi Max, I didn't touch AlgorithmId.java class in this RFE as these provider-defined HmacSHA3-xxx oids alias mapping are picked up by AlgorithmId.java inside its computeOidTable() method. AlgorithmId class should be still be able to find the String->oid string mapping from its oidTable field. But the constructed AlgorithmId object will return the oid string instead of the use-friendly name when its getName() is called. As I have started prototyping changes for minimizing the current duplication of oids in various providers and sun.security.x509.AlgorithmId class, I choose to leave AlgorithmId class out for now. I am on the fence about this and if you saw value for returning the friendly name for Hmac SHA3, I could add another 4 oid constants for Hmac SHA3 and add their name mapping to the AlgorithmId.nameTable. Majority of these will be changed during the oid duplication cleanup which I will file an RFE to track once this prototyping is somewhat done. Thanks, Valerie On 3/19/2020 5:57 PM, Weijun Wang wrote: Are we going to add the new OIDs/names to AlgorithmId.java? There are quite some duplicated info everywhere. Thanks, Max On Mar 20, 2020, at 8:07 AM, Valerie Peng wrote: Webrev updated: http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/ Thanks, Valerie On 3/19/2020 1:33 PM, Valerie Peng wrote: Hi Bernd, Thanks for the comments~ Please find additional reply inline. On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? Good catch, will add a return. The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) Some of the test values use ":" as a separator. When such separator is present, it takes a longer string to represent the same number of bytes. So, depending on whether the separator is used, the default number of bytes is calculated differently. BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. Support for the truncated SHA512 variants is mainly done in a separate/earlier RFE, i.e. JDK-8051408 (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a comment to the RFE to make this clear. Regards, Valerie hTH Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Valerie Peng Gesendet: Wednesday, March 18, 2020 11:57:37 PM An: OpenJDK Dev list Betreff: [15] RFR 8172680: Support SHA-3 based Hmac algorithms 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
The CSR looks straightforward to me. You might mention that these algorithms are Standard Names in the specification section, but it's just a nit. --Jamil On 3/19/2020 3:50 PM, Valerie Peng wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8241325 Please review~ Thanks! Valerie On 3/19/2020 12:54 PM, Valerie Peng wrote: And CSR also. On 3/19/2020 12:53 PM, Valerie Peng wrote: Hi Sean, Yes, thanks for the reminder. I will file the release note and provider doc issue for this. Valerie On 3/19/2020 8:08 AM, Sean Mullan wrote: Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Are we going to add the new OIDs/names to AlgorithmId.java? There are quite some duplicated info everywhere. Thanks, Max > On Mar 20, 2020, at 8:07 AM, Valerie Peng wrote: > > Webrev updated: http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/ > > Thanks, > Valerie > On 3/19/2020 1:33 PM, Valerie Peng wrote: >> Hi Bernd, >> >> Thanks for the comments~ Please find additional reply inline. >> >> On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: >>> Hello Valerie. >>> >>> In MacKAT 121 you would get a NPE if the catch prints the skip message, >>> probably needs an additional return; guard? >> Good catch, will add a return. >> >>> >>> The BAOS default length change in parse() was not immediately clear to me? >>> (Maybe next s. Base64?) >> Some of the test values use ":" as a separator. When such separator is >> present, it takes a longer string to represent the same number of bytes. So, >> depending on whether the separator is used, the default number of bytes is >> calculated differently. >> >>> >>> BTW It is good to see that you also add truncated SHA512 variants. It's not >>> mentioned in commit message or RFE. >> Support for the truncated SHA512 variants is mainly done in a >> separate/earlier RFE, i.e. JDK-8051408 >> (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing >> OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated >> SHA512 variants. I can add a comment to the RFE to make this clear. >> >> Regards, >> >> Valerie >> >>> >>> hTH >>> Bernd >>> >>> >>> >>> -- >>> http://bernd.eckenfels.net >>> Von: security-dev im Auftrag von >>> Valerie Peng >>> Gesendet: Wednesday, March 18, 2020 11:57:37 PM >>> An: OpenJDK Dev list >>> Betreff: [15] RFR 8172680: Support SHA-3 based Hmac algorithms >>> >>> >>> 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Webrev updated: http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/ Thanks, Valerie On 3/19/2020 1:33 PM, Valerie Peng wrote: Hi Bernd, Thanks for the comments~ Please find additional reply inline. On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? Good catch, will add a return. The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) Some of the test values use ":" as a separator. When such separator is present, it takes a longer string to represent the same number of bytes. So, depending on whether the separator is used, the default number of bytes is calculated differently. BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. Support for the truncated SHA512 variants is mainly done in a separate/earlier RFE, i.e. JDK-8051408 (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a comment to the RFE to make this clear. Regards, Valerie hTH Bernd -- http://bernd.eckenfels.net *Von:* security-dev im Auftrag von Valerie Peng *Gesendet:* Wednesday, March 18, 2020 11:57:37 PM *An:* OpenJDK Dev list *Betreff:* [15] RFR 8172680: Support SHA-3 based Hmac algorithms 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
CSR: https://bugs.openjdk.java.net/browse/JDK-8241325 Please review~ Thanks! Valerie On 3/19/2020 12:54 PM, Valerie Peng wrote: And CSR also. On 3/19/2020 12:53 PM, Valerie Peng wrote: Hi Sean, Yes, thanks for the reminder. I will file the release note and provider doc issue for this. Valerie On 3/19/2020 8:08 AM, Sean Mullan wrote: Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
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 0x02b0UL #define CKM_SHA3_256_HMAC 0x02b1UL #define CKM_SHA3_256_HMAC_GENERAL 0x02b2UL #define CKM_SHA3_224 0x02b5UL #define CKM_SHA3_224_HMAC 0x02b6UL #define CKM_SHA3_224_HMAC_GENERAL 0x02b7UL #define CKM_SHA3_384 0x02c0UL #define CKM_SHA3_384_HMAC 0x02c1UL #define CKM_SHA3_384_HMAC_GENERAL 0x02c2UL #define CKM_SHA3_512 0x02d0UL #define CKM_SHA3_512_HMAC 0x02d1UL #define CKM_SHA3_512_HMAC_GENERAL 0x02d2UL
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Hi Bernd, Thanks for the comments~ Please find additional reply inline. On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? Good catch, will add a return. The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) Some of the test values use ":" as a separator. When such separator is present, it takes a longer string to represent the same number of bytes. So, depending on whether the separator is used, the default number of bytes is calculated differently. BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. Support for the truncated SHA512 variants is mainly done in a separate/earlier RFE, i.e. JDK-8051408 (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a comment to the RFE to make this clear. Regards, Valerie hTH Bernd -- http://bernd.eckenfels.net *Von:* security-dev im Auftrag von Valerie Peng *Gesendet:* Wednesday, March 18, 2020 11:57:37 PM *An:* OpenJDK Dev list *Betreff:* [15] RFR 8172680: Support SHA-3 based Hmac algorithms 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
And CSR also. On 3/19/2020 12:53 PM, Valerie Peng wrote: Hi Sean, Yes, thanks for the reminder. I will file the release note and provider doc issue for this. Valerie On 3/19/2020 8:08 AM, Sean Mullan wrote: Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Hi Sean, Yes, thanks for the reminder. I will file the release note and provider doc issue for this. Valerie On 3/19/2020 8:08 AM, Sean Mullan wrote: Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. hTH Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Valerie Peng Gesendet: Wednesday, March 18, 2020 11:57:37 PM An: OpenJDK Dev list Betreff: [15] RFR 8172680: Support SHA-3 based Hmac algorithms 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
Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
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 0x02b0UL #define CKM_SHA3_256_HMAC 0x02b1UL #define CKM_SHA3_256_HMAC_GENERAL 0x02b2UL #define CKM_SHA3_224 0x02b5UL #define CKM_SHA3_224_HMAC 0x02b6UL #define CKM_SHA3_224_HMAC_GENERAL 0x02b7UL #define CKM_SHA3_384 0x02c0UL #define CKM_SHA3_384_HMAC 0x02c1UL #define CKM_SHA3_384_HMAC_GENERAL 0x02c2UL #define CKM_SHA3_512 0x02d0UL #define CKM_SHA3_512_HMAC 0x02d1UL #define CKM_SHA3_512_HMAC_GENERAL 0x02d2UL
[15] RFR 8172680: Support SHA-3 based Hmac algorithms
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
