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.peng at 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