Re: RFR JDK-8000415: Add support for SHA-3

Sean, I have added the values to the exception message as u suggested. As for the test vectors, I already put them (some of them) in separate internal tests for SUN and OracleUcrypto provider respectively. PKCS11 provider is not yet updated with the SHA-3 support, when it does, it will has its

Re: RFR JDK-8000415: Add support for SHA-3

Valerie, some comments on supportability of the new code. Some handling could be improved to contain context perhaps : sun/security/provider/SHA3.java +if (numOfPadding < 1) { +throw new ProviderException("Incorrect pad size"); Can we print the numOfPadding value ? +

Re: RFR JDK-8000415: Add support for SHA-3

Hi Tony, Thanks for the review. I have deleted line 161 of UcryptoProvider.java as that's the intention. As for ucrypto_version enhancement, it's not that critical for this. I will note it in another ucrypto bug and we can do it there. Hmm, the internal operations of SHA-3 are already

Re: RFR JDK-8000415: Add support for SHA-3

On 5/12/2016 10:38 AM, Anthony Scarpino wrote: On 05/04/2016 07:08 PM, Valerie Peng wrote: Hi, Can someone help reviewing the changes for SHA-3? The result has been validated against the NIST test vectors (for BYTE-ONLY impls, i.g. input which are multiples of bytes). The feature complete

Re: RFR JDK-8000415: Add support for SHA-3

On 05/04/2016 07:08 PM, Valerie Peng wrote: Hi, Can someone help reviewing the changes for SHA-3? The result has been validated against the NIST test vectors (for BYTE-ONLY impls, i.g. input which are multiples of bytes). The feature complete date is coming up in a week or two. So, if this can

Re: RFR JDK-8000415: Add support for SHA-3

> On May 6, 2016, at 7:44 AM, Valerie Peng wrote: > > > Yes, I think it's better to deal with this before you call the methods in > ByteArrayAccess class. > Your code snippet looks good. > Valerie > Good. Then the only conflict between our changesets is we both

Re: RFR JDK-8000415: Add support for SHA-3

Yes, I think it's better to deal with this before you call the methods in ByteArrayAccess class. Your code snippet looks good. Valerie On 5/5/2016 1:16 AM, Wang Weijun wrote: On May 5, 2016, at 11:06 AM, Wang Weijun wrote: So this assumes len % 4 == 0. If you

Re: RFR JDK-8000415: Add support for SHA-3

I think we should continue with the "len should be multiples of 8" assumption for l2bBig. Just like other methods in ByteArrayAccess.java, when len should be multiples of 4 when dealing with int[], and multiples of 8 when dealing with long[]. Valerie On 5/4/2016 8:06 PM, Wang Weijun wrote:

Re: RFR JDK-8000415: Add support for SHA-3

There is a separate bug id to keep track of the doc changes, see https://bugs.openjdk.java.net/browse/JDK-8004078 Valerie On 5/5/2016 10:57 AM, Michael StJohns wrote: Quick side question - how does the "Standard Algorithm Names" doc get updated to include SHA3 stuff? Should it be folded into

Re: RFR JDK-8000415: Add support for SHA-3

Quick side question - how does the "Standard Algorithm Names" doc get updated to include SHA3 stuff? Should it be folded into this change or? Mike On 5/4/2016 10:08 PM, Valerie Peng wrote: Hi, Can someone help reviewing the changes for SHA-3? The result has been validated against the NIST

Re: RFR JDK-8000415: Add support for SHA-3

> On May 5, 2016, at 11:06 AM, Wang Weijun wrote: > > So this assumes len % 4 == 0. > > If you follow this, you might need to add Unsafe.putInt for the last 4 bytes. > > On the other hand, if you think len % 8 == 0 should always be true, I can do > some

Re: RFR JDK-8000415: Add support for SHA-3

Hi Valerie This is not exactly a code review. I noticed you've updated static void l2bBig(long[] in, int inOfs, byte[] out, int outOfs, int len) in ByteArrayAccess.java. I also updated it during the implementation of SHA-512/224 (a part of DRBG) because here len is 28 but the original