Re: A few updates to JEP 411: Deprecate the Security Manager for Removal
Thanks Sean, Has there been any progress with JDK-8264713? https://bugs.openjdk.java.net/browse/JDK-8264713 Regards, Peter. On 16/07/2021 11:44 pm, Sean Mullan wrote: JEP 411 has been updated with a few changes: 1. The "Description" section [1] has been updated with more details on our plans for phasing out the Security Manager in Java 18 and later. 2. The "Issue warnings" section [2] has been updated with the warning messages that are emitted at startup and run time when a Security Manager has been enabled. 3. JEP 411 has been moved to the Completed state as all required tasks have been completed. Thanks, Sean [1] https://openjdk.java.net/jeps/411#Description [2] https://openjdk.java.net/jeps/411#Issue-warnings
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 16 Jul 2021 20:49:20 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 146: > >> 144: } >> 145: state = new long[2]; >> 146: subkeyHtbl = new long[2*57]; // 48 keys for the interleaved >> implementation, 8 for avx-ghash implementation and one for the original key > > nit: the comment is too long, i.e. > 80 Ah.. I forgot I didn't change GHASH with my changes.. but I'll fix that thanks > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java > line 743: > >> 741: dst.array(), dst.arrayOffset() + >> dst.position(), >> 742: gctr, ghash); >> 743: } > > Can we use another ByteBuffer variable to avoid almost-duplicate calls? > > ByteBuffer ct = (encryption? dst : src); > rlen -= GaloisCounterMode.implGCMCrypt(src.array(), > src.arrayOffset() + src.position(), > src.remaining(), > ct.array(), ct.arrayOffset() + ct.position(), > dst.array(), dst.arrayOffset() + dst.position(), > gctr, ghash); That maybe a better choice - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 16 Jul 2021 00:10:52 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 992:
>>
>>> 990: */
>>> 991: byte[] overlapDetection(byte[] in, int inOfs, byte[] out, int
>>> outOfs) {
>>> 992: if (in == out && (!encryption || inOfs < outOfs)) {
>>
>> So, we will always allocate an output buffer for decryption if in==out? Why
>> just decryption? Update the javadoc for this method with the reason?
>
> If the crypto is decryption in-place, an internal output buffer is needed in
> case the auth tag fails, otherwise the input buffer would be zero'ed.
If decryption fails with a bad auth tag, the in is not overwritten because it's
in-place. Encryption is not needed because there is nothing to check. I can
add a comment.
-
PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures >> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES >> and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional > commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 146: > 144: } > 145: state = new long[2]; > 146: subkeyHtbl = new long[2*57]; // 48 keys for the interleaved > implementation, 8 for avx-ghash implementation and one for the original key nit: the comment is too long, i.e. > 80 - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated AES-GCM intrinsic to match latest Java Code
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
629:
> 627: GCTR gctr;
> 628: GHASH ghash;
> 629: GCMOperation op;
It seems clearer to initialize "op" in GCMEngine ctor since it's declared here.
There is already logic in its method checking whether we are doing encryption
or decryption.
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
650:
> 648: int originalOutOfs = 0;
> 649: byte[] in;
> 650: byte[] out;
The name "in", "out" are almost used in all calls, it's hard to tell when these
two are actually used. Can we rename them to make them more unique?
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
724:
> 722: } else {
> 723: ct = in;
> 724: }
This can just be:
byte[] ct = (encryption? out : in);
Since you only use this 'ct' variable inside the else block on line 746, move
this down to that block.
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
743:
> 741: dst.array(), dst.arrayOffset() +
> dst.position(),
> 742: gctr, ghash);
> 743: }
Can we use another ByteBuffer variable to avoid almost-duplicate calls?
ByteBuffer ct = (encryption? dst : src);
rlen -= GaloisCounterMode.implGCMCrypt(src.array(),
src.arrayOffset() + src.position(), src.remaining(),
ct.array(), ct.arrayOffset() + ct.position(),
dst.array(), dst.arrayOffset() + dst.position(),
gctr, ghash);
-
PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 16 Jul 2021 00:32:16 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java > line 629: > >> 627: GCTR gctr; >> 628: GHASH ghash; >> 629: GCMOperation op; > > It seems clearer to initialize "op" in GCMEngine ctor since it's declared > here. There is already logic in its method checking whether we are doing > encryption or decryption. Now that you have GCMOperation op, but there is still if-else blocks checking whether it's encryption/decryption and uses gctr and ghash instead of op. Looks like a bit adhoc? Can GaloisCounterMode.implGCMCrypt(...) just take GCMOperation op instead, no need for ct, ctOfs, gctr and ghash? - PR: https://git.openjdk.java.net/jdk/pull/4019
[jdk17] Integrated: 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA
On Thu, 15 Jul 2021 15:04:04 GMT, Christoph Langer wrote: > The test is failing since 8th of July. Let's exclude it for now. This pull request has now been integrated. Changeset: 1350e2bd Author:Christoph Langer URL: https://git.openjdk.java.net/jdk17/commit/1350e2bd225b2032b929f9c68ba297833ad6b2bf Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA Reviewed-by: mbaesken - PR: https://git.openjdk.java.net/jdk17/pull/251
A few updates to JEP 411: Deprecate the Security Manager for Removal
JEP 411 has been updated with a few changes: 1. The "Description" section [1] has been updated with more details on our plans for phasing out the Security Manager in Java 18 and later. 2. The "Issue warnings" section [2] has been updated with the warning messages that are emitted at startup and run time when a Security Manager has been enabled. 3. JEP 411 has been moved to the Completed state as all required tasks have been completed. Thanks, Sean [1] https://openjdk.java.net/jeps/411#Description [2] https://openjdk.java.net/jeps/411#Issue-warnings
[jdk17] Withdrawn: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs
On Fri, 18 Jun 2021 15:21:06 GMT, Sean Mullan wrote: > Please review this fix to backout the change to Disable SHA-1 Signed JARs > from JDK 17 due to a startup performance regression (see > https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now address > the performance issue in JDK 18, which will also allow for more bake time. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk17/pull/100
Re: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs
On Thu, 15 Jul 2021 20:46:44 GMT, Kevin Rushforth wrote: >> Please review this fix to backout the change to Disable SHA-1 Signed JARs >> from JDK 17 due to a startup performance regression (see >> https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now >> address the performance issue in JDK 18, which will also allow for more bake >> time. > > @seanjmullan Since the fix for this bug was integrated via PR #113 can you > close this PR to withdraw it? @kevinrushforth Done. - PR: https://git.openjdk.java.net/jdk17/pull/100
