Re: RFR: 8270317: Large Allocation in CipherSuite [v4]
On Thu, 22 Jul 2021 19:01:02 GMT, Clive Verghese wrote:
>> ### Benchmark results
>>
>> I have benchmarked 3 cases.
>>
>> 1. The current situation.
>>
>> Benchmark
>> (cipherSuite) Mode CntScore Error Units
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op
>>
>>
>> 2. Use `static final array` instead of calling `CipherSuite.values` each
>> time.
>>
>> Benchmark
>> (cipherSuite) Mode Cnt Score Error Units
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op
>>
>>
>> 3. Using Hashmap for lookup instead of iterating through the array each
>> time. (Method in this PR)
>>
>> Benchmark
>> (cipherSuite) Mode Cnt Score Error Units
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op
>>
>>
>> I have picked 4 cipher suite from the start of the list and are roughly 10
>> positions apart. I have opted to go with HashMap for name and id lookup as
>> they provide a more consistent times and benchmarks are similar for the
>> first few cipher suits in the enum as well.
>
> Clive Verghese has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add blank space before and after the for loop
Marked as reviewed by djelin...@github.com (no known OpenJDK username).
src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 971:
> 969:
> 970: boolean found = false;
> 971: for (CipherSuite cs : allowedCipherSuites) {
We can avoid this loop; look up the cipher by name first (`cs = nameOf(name)`),
then check for supported protocols.
Other than that, LGTM.
-
PR: https://git.openjdk.java.net/jdk/pull/4783
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Thu, 22 Jul 2021 22:41:03 GMT, Valerie Peng wrote: >> This is able in-place, not about two separate buffers.. zeroing happens >> somewhere else for all decryption bad buffers > > Yes, I know. Basically, we are trying to optimize performance by trying to > write into the supplied buffers (out) as much as we can. But then when tag > verification failed, the "written" bytes are erased w/ 0. Ideal case would be > not to touch the output buffer until after the tag verification succeeds. > Isn't this the previous approach? Verify the tag first and then write out the > plain text afterwards. With this new intrinsic doing both ghash and gctr at the same time, I cannot do the that ghash check first before the gctr op. I wish I could - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Thu, 22 Jul 2021 18:36:16 GMT, Anthony Scarpino wrote: >> Hmm ok, so if it's not decryption in-place, then output buffer would still >> be zero'ed when the auth tag failed, but this is ok? > > This is able in-place, not about two separate buffers.. zeroing happens > somewhere else for all decryption bad buffers Yes, I know. Basically, we are trying to optimize performance by trying to write into the supplied buffers (out) as much as we can. But then when tag verification failed, the "written" bytes are erased w/ 0. Ideal case would be not to touch the output buffer until after the tag verification succeeds. Isn't this the previous approach? Verify the tag first and then write out the plain text afterwards. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: JEP411: Missing use-case: Security Manager and Java Scripting (JSR 223)
Hi Sean,
We are using Rhino 1.7.12
On Wed, Jul 21, 2021 at 10:31 PM Sean Mullan wrote:
> Hi,
>
> I am not an expert in JSR 223. However, some JSR 223 implementations
> include a mechanism for restricting access to Java classes, for example
> Nashorn [1] and Rhino [2], which might be sufficient for your needs. (Note,
> Nashorn was deprecated and removed from JDK 15 [3]). I think most of the
> permissions you list below can be mapped to a small list of Java classes
> that check those permissions. Also, with strong encapsulation of JDK
> internals enforced by default in JDK 17 [4], you get additional protection
> that is not dependent on the Security Manager.
>
> What JSR 223 implementation do you use?
>
> --Sean
>
> [1]
> https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction
> [2]
> https://mozilla.github.io/rhino/javadoc/org/mozilla/javascript/ClassShutter.html
> [3] https://openjdk.java.net/jeps/372
> [4] https://openjdk.java.net/jeps/403
>
> On 7/21/21 12:35 PM, Alexey Shponarsky wrote:
>
> Hello,
>
> At Jelastic PaaS, we are using SecurityManager within Java Scripting (JSR
> 223). Specifically, Java Scripting allows us and our customers to easily
> extend the core platform functionality with custom logic. The developers
> can execute their custom scriptlets inside a Java Scripting runtime
> environment with pre-injected core platform API methods. For example,
>
>
>
> //@req(pathFrom, pathTo)
>
> var mountFrom = "${nodes.build.first.id}",
>
> envName = "${settings.targetEnv}",
>
> mountTo = "cp";
>
> var resp = jelastic.env.file.RemoveMountPointByGroup(envName, session,
> mountTo, pathTo);
>
> if (resp.result != 0) return resp;
>
> return jelastic.env.file.AddMountPointByGroup(envName, session, mountTo,
> pathTo, 'nfs', null, pathFrom, mountFrom, '', false);
>
>
>
> As Java Scripting engine / technology provides quite powerful runtimes, we
> have to restrict certains actions such as execution of any reflection
> methods, change of any system environment variables, exit, calling some
> dangerous static methods, reading files outside of the sandbox folder, etc.
> The SecurityManager mechanism provided an ability to configure permissions
> easily.
>
>
>
> To achieve this we create an instance of AccessControlContext with
> required permissions and pass it to AccessController.doPrivileged
>
> method:
>
>
>
> //Create list of Permission:
>
> Collection perms = new LinkedList();
>
> perms.add(new RuntimePermission("createClassLoader"));
>
> perms.add(new RuntimePermission("getClassLoader"));
>
> perms.add(new RuntimePermission("accessDeclaredMembers"));
>
> perms.add(new RuntimePermission("getProtectionDomain"));
>
> perms.add(new PropertyPermission("*", "read"));
>
> perms.add(new SocketPermission("*", "connect,accept,resolve"));
>
> perms.add(new SocketPermission("localhost:0-",
> "connect,accept,resolve,listen"));
>
>
>
>
>
> //Create AccessControlContext
>
> ProtectionDomain domain = new ProtectionDomain(new CodeSource(null, (
> Certificate[]) null), perms);
>
> AccessControlContext acc = new AccessControlContext(new
> ProtectionDomain[]{domain});
>
>
>
> //Run untrusted code using created AccessControlContext
>
> @Override
>
> public ScriptEvalResponse call() throws Exception {
>
>Object obj = AccessController.doPrivileged(new PrivilegedAction()
> {
>
>
>
>@Override
>
>public Object run() {
>
>try {
>
>Object response = compiledScript.eval(ctx);
>
>ScriptEvalResponse evalResponse = new ScriptEvalResponse(
> Response.OK);
>
>evalResponse.setResponse(response);
>
>return evalResponse;
>
>} catch (Exception ex) {
>
>logger.debug("Error occurred during eval script:", ex);
>
>return ex;
>
>}
>
>}
>
>}, acc);
>
>if (obj instanceof Exception) {
>
>throw (Exception) obj;
>
>}
>
>return (ScriptEvalResponse) obj;
>
> }
>
>
>
>
>
> How can we implement a similar solution after the removal of
> SecurityManager? Could you help us to find an alternative?
>
>
> --
> Alexey Shponarsky Director of R
> Twitter Facebook
> LinkedIn
>
>
>
>
--
Alexey Shponarsky Director of R
Twitter Facebook
LinkedIn
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 16 Jul 2021 00:09:37 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 611: > >> 609: outOfs + len); >> 610: ghash.update(ct, ctOfs, segments); >> 611: ctOfs = len; > > This does not look right when the initial value of ctOfs != 0. Yeah that doesn't look right - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8270317: Large Allocation in CipherSuite [v3]
On Thu, 22 Jul 2021 18:50:08 GMT, Xue-Lei Andrew Fan wrote:
>> Clive Verghese has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add allowed and default lists
>
> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 866:
>
>> 864: List allowedCS = new ArrayList<>();
>> 865: List defaultCS = new ArrayList<>();
>> 866: for(CipherSuite cs : CipherSuite.values()) {
>
> I may add blank lines before and after the for-loop block.
Than you @XueleiFan for approving the PR.
I have added the black lines before and after the PR.
-
PR: https://git.openjdk.java.net/jdk/pull/4783
Re: RFR: 8270317: Large Allocation in CipherSuite [v3]
On Thu, 22 Jul 2021 18:37:53 GMT, Clive Verghese wrote:
>> ### Benchmark results
>>
>> I have benchmarked 3 cases.
>>
>> 1. The current situation.
>>
>> Benchmark
>> (cipherSuite) Mode CntScore Error Units
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op
>>
>>
>> 2. Use `static final array` instead of calling `CipherSuite.values` each
>> time.
>>
>> Benchmark
>> (cipherSuite) Mode Cnt Score Error Units
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op
>>
>>
>> 3. Using Hashmap for lookup instead of iterating through the array each
>> time. (Method in this PR)
>>
>> Benchmark
>> (cipherSuite) Mode Cnt Score Error Units
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op
>> CipherSuiteBench.benchmarkCipherSuite
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op
>>
>>
>> I have picked 4 cipher suite from the start of the list and are roughly 10
>> positions apart. I have opted to go with HashMap for name and id lookup as
>> they provide a more consistent times and benchmarks are similar for the
>> first few cipher suits in the enum as well.
>
> Clive Verghese has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add allowed and default lists
Looks good to me. Thank you!
src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 866:
> 864: List allowedCS = new ArrayList<>();
> 865: List defaultCS = new ArrayList<>();
> 866: for(CipherSuite cs : CipherSuite.values()) {
I may add blank lines before and after the for-loop block.
-
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/4783
Re: RFR: 8270317: Large Allocation in CipherSuite [v4]
> ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark > (cipherSuite) Mode CntScore Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each > time. > > Benchmark > (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. > (Method in this PR) > > Benchmark > (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 > positions apart. I have opted to go with HashMap for name and id lookup as > they provide a more consistent times and benchmarks are similar for the first > few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Add blank space before and after the for loop - Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/c0a21c5d..158714cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4783=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4783=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Mon, 19 Jul 2021 23:41:49 GMT, Valerie Peng wrote: >> 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. > > Hmm ok, so if it's not decryption in-place, then output buffer would still be > zero'ed when the auth tag failed, but this is ok? This is able in-place, not about two separate buffers.. zeroing happens somewhere else for all decryption bad buffers - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8270317: Large Allocation in CipherSuite [v3]
> ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark > (cipherSuite) Mode CntScore Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each > time. > > Benchmark > (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. > (Method in this PR) > > Benchmark > (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 > positions apart. I have opted to go with HashMap for name and id lookup as > they provide a more consistent times and benchmarks are similar for the first > few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Add allowed and default lists - Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/aec4f54c..c0a21c5d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4783=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4783=01-02 Stats: 57 lines in 1 file changed: 12 ins; 26 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783
Re: RFR: 8270317: Large Allocation in CipherSuite
On Thu, 22 Jul 2021 00:11:56 GMT, Xue-Lei Andrew Fan wrote: >> Updated Benchmarks in Throughput mode >> >> ### Current >> >> Benchmark >> (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite >> TLS_AES_256_GCM_SHA384 thrpt 25 8050.787 ? 232.335 ops/ms >> CipherSuiteBench.benchmarkCipherSuite >> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 8165.124 ? 283.718 >> ops/ms >> CipherSuiteBench.benchmarkCipherSuite >> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 7827.758 ? 293.311 ops/ms >> CipherSuiteBench.benchmarkCipherSuite >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 7768.286 ? 181.399 ops/ms >> >> >> ### ArrayList >> >> Benchmark >> (cipherSuite) Mode CntScore Error Units >> CipherSuiteBench.benchmarkCipherSuite >> TLS_AES_256_GCM_SHA384 thrpt 25 100.626 ? 0.294 ops/us >> CipherSuiteBench.benchmarkCipherSuite >> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 32.793 ? 0.804 ops/us >> CipherSuiteBench.benchmarkCipherSuite >> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 21.162 ? 0.217 ops/us >> CipherSuiteBench.benchmarkCipherSuite >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 18.220 ? 0.903 ops/us >> >> >> ### Hashmap >> >> Benchmark >> (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite >> TLS_AES_256_GCM_SHA384 thrpt 25 63.836 ? 4.517 ops/us >> CipherSuiteBench.benchmarkCipherSuite >> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 69.983 ? 8.965 ops/us >> CipherSuiteBench.benchmarkCipherSuite >> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 68.091 ? 7.404 ops/us >> CipherSuiteBench.benchmarkCipherSuite >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 52.831 ? 4.317 ops/us >> >> >> I am currently looking into the JFR profiles to identify why there is a >> difference in benchmarks with regards the different cipher suits in the >> current version vs the arraylist. > >> Updated Benchmarks in Throughput mode > > Thank you very much for the update. > >> I am currently looking into the JFR profiles to identify why there is a >> difference in benchmarks with regards the different cipher suits in the >> current version vs the arraylist. > > I guess the garbage collection plays a role here. Hi @XueleiFan, Thank you for the feedback. I have update the pull requests addressing your comments. - PR: https://git.openjdk.java.net/jdk/pull/4783
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Tue, 20 Jul 2021 01:35:04 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 762: > >> 760: >> 761: dst.put(out, 0, rlen); >> 762: processed += srcLen; > > It seems that callers of this implGCMCrypt() method such as > GCMEngine.doLastBlock() adds the returned value to the "processed" field > which looks like double counting? However, some caller such as > GCMEncrypt.doUpdate() does not. Seems inconsistent and may lead to wrong > value for the "processed" field? All the callers that use GCMOperations, ie op.update(...), have the processed value updated. implGCMCrypt() calls op.update() and updates the value. It cannot double count 'processed' is not updated after implGCMCrypt(). I can see your point, but the other methods do not have access to 'processed' and would mean I copy that line 3 times elsewhere. I'd rather keep it as is - PR: https://git.openjdk.java.net/jdk/pull/4019
RFR: 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails
Test certificates are updated for now. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. - Commit messages: - 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails Changes: https://git.openjdk.java.net/jdk/pull/4878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4878=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243543 Stats: 246 lines in 2 files changed: 49 ins; 7 del; 190 mod Patch: https://git.openjdk.java.net/jdk/pull/4878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4878/head:pull/4878 PR: https://git.openjdk.java.net/jdk/pull/4878
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Mon, 19 Jul 2021 19:35: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 761: > >> 759: } >> 760: >> 761: dst.put(out, 0, rlen); > > This looks belong to the above if-block? I wonder how this have not affected > the operation to fail. Perhaps the existing regression tests did not cover > the 'rlen < blockSize' case. If the code in the above if-block is not run, > this outsize dst.put(...) call would put extra output bytes into the output > buffer. Yes... this one and the ct offset problem earlier I would have expected the regression test it pick the mistake. There should be tests that catch this.. I'm not sure what's up. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Mon, 19 Jul 2021 19:22:53 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 729:
>
>> 727:
>> 728: if (src.hasArray() && dst.hasArray()) {
>> 729: int l = rlen;
>
> Remove this "l" variable since it's not used?
The code needs some reorganizing
-
PR: https://git.openjdk.java.net/jdk/pull/4019
RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error
I have updated revoked test certificate but this test may again fail in Sept as test certificate expire leading to OCSP error. CA is not willing to issue test certificates with more than 90 day validity so this test will fail every quarter. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. - Commit messages: - 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error Changes: https://git.openjdk.java.net/jdk/pull/4877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4877=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270280 Stats: 29 lines in 2 files changed: 0 ins; 4 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4877/head:pull/4877 PR: https://git.openjdk.java.net/jdk/pull/4877
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 16 Jul 2021 00:31:43 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 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? ok - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Tue, 20 Jul 2021 22:36:28 GMT, Valerie Peng wrote: >> Initializing op in abstract GCMEngine would mean another 'if(encryption)', >> when that would not be needed in the GCMEncrypt() or GCMDecrypt(). I don't >> see why that is clearer. >> >> GaloisCounterMode.implGCMCrypt(...) is the intrinsic, so I have to use what >> is used by hotspot. > > Seems strange to have GCMOperation op defined in GCMEngine but not > initialized, nor used. The methods in GCMEngine which use op has an argument > named op anyway. Either you just use the "op" field (remove the "op" > argument) or the "op" argument (move the op field to GCMEncrypt/GCMDecrypt > class). Having both looks confusing. Ok.. Moving it into GCMEncrypt makes sense. Now that I look at the code GCMDecrypt only uses it when passed to a method. GCMEncrypt uses it - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java [v3]
On Fri, 18 Jun 2021 13:24:17 GMT, Abdul Kolarkunnu wrote: >> ParamsTest is an interop test between keytool <-> openssl. There are some >> manual steps listed in jdk/sun/security/pkcs12/params/README to perform >> after the execution of jtreg execution. So this test is to perform that >> manual steps. > > Abdul Kolarkunnu has updated the pull request incrementally with one > additional commit since the last revision: > > 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java I am trying to fully automate this instead of a manual test, because of some other high priority works I had paused that work, will resume it soon. - PR: https://git.openjdk.java.net/jdk/pull/4413
