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 MaxOn May 5, 2016, at 10:08 AM, Valerie Peng<[email protected]> 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
