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
