RFR JDK-8000415: Add support for SHA-3

[Valerie Peng]

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 operating on long[][] 
and I doubt that we will have the same performance gain as in the GHASH 
case here,
The java APIs passes data in byte[], so at some point, we have to 
convert all the longs back to bytes. But I agree that we should avoid 
unnecessary conversions.
Performance task has been planned and we will do a closer inspection on 
this.

Valerie

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 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
>
> Just a few minor things.
>
> UcryptoProvider.java:161
> Did you mean to only comment it out and not delete it?
>
> nativeFunc.c:
> I noticed it is checking the library functions via dlsym.  You could 
> have a conditional check on the version of the library via 
> ucrypto_version, then do the dlsym calls if it is supported.
>
>
> I think there is a performance enhancement that I would not hold up 
> for this changeset.  Changing the byte[]'s to long[] might give a good 
> performance gain.  A similar change was done to GHASH.java which 
> resulted in a 10x performance increase.  Given the internal methods 
> appear to use long[][], and lanes are in longs it would probably help. 
> But it most likely require a change to add 
> DigestBase.implCompress(long[], int) and DigestBase.and 
> implDigest(long[], int).  Probably a low priority RFE.
>
> Tony
>