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

[Valerie Peng]

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 <valerie.p...@oracle.com> 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 <security-dev-boun...@openjdk.java.net> im Auftrag von Valerie Peng 
<valerie.p...@oracle.com>
Gesendet: Wednesday, March 18, 2020 11:57:37 PM
An: OpenJDK Dev list <security-dev@openjdk.java.net>
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