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

[Valerie Peng]

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:
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 l2bBig assumes len % 8 == 0.

My change is

@@ -448,10 +448,12 @@
-            out[outOfs++] = (byte)(i>>  24);
-            out[outOfs++] = (byte)(i>>  16);
-            out[outOfs++] = (byte)(i>>   8);
-            out[outOfs++] = (byte)(i      );
+            if (outOfs<  len) {     // SHA-512/224 is 28 bytes
+                out[outOfs++] = (byte) (i>>  24);
+                out[outOfs++] = (byte) (i>>  16);
+                out[outOfs++] = (byte) (i>>  8);
+                out[outOfs++] = (byte) (i);
+            }

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 expand-and-shrink inside SHA5.java. My DRBG chanegset is not pushed yet.

Thanks
Max

On May 5, 2016, at 10:08 AM, Valerie Peng<valerie.p...@oracle.com>  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 be 
reviewed in a week or so, that'd be great.

The changes for SUN providers are quite straight-forward, e.g. SHA-3 digest 
impls based on FIPS PUB 202.
As for OracleUcrypto provider, Solaris SHA-3 support is through new libucrypto 
digest APIs (added in Solaris 12) instead of the libmd.
When running on Solaris 12, the new libucrypto APIs will be used. Otherwise, 
libmd will be used.
Changes for OracleUcrypto providers:
- add JNI code for the new libucrypto digest APIs
- code refactoring, e.g. move the libmd-related code to classes with MD suffix
- run-time mechanism number assignment (used to be hardcoded values)
- better error reporting

RFE: https://bugs.openjdk.java.net/browse/JDK-8000415
Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/

Thanks,
Valerie