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