RFR JDK-8000415: Add support for SHA-3

Anthony Scarpino anthony.scarpino at oracle.com
Thu May 12 17:38:02 UTC 2016


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




More information about the security-dev mailing list