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
