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 <[email protected]> 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 <[email protected]> im Auftrag von Valerie Peng
<[email protected]>
Gesendet: Wednesday, March 18, 2020 11:57:37 PM
An: OpenJDK Dev list <[email protected]>
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
