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
