On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess wrote:
>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> clean up Calendar
I gave a quick look at the security files touched and seems straightforward. I
didn't see any
On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeliński wrote:
>> Session ticket extension should only contain pre-TLS1.3 stateless session
>> tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> Daniel Jeliński has updated the pull request incrementally with one
> additional commit
On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeliński wrote:
>> Session ticket extension should only contain pre-TLS1.3 stateless session
>> tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> Daniel Jeliński has updated the pull request incrementally with one
> additional commit
On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only
On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this fix to allow a read-only 'src' buffer to be used with
> SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher
> operation when a read-only buffer is pass
On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote:
> Let ECDSA's `engineGetParameters()` always return null. At the same time,
> remove the remembered `sigParams` field. One behavior change is that after
> calling `setParameter()`, one can call `init()` again with a key using
> different
On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only
buffer for in-place
> decryption was a performance decision.
>
> Tony
Anthony Scarpino has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commits:
- review update
- update some nits
- PR ready
- Initial
-
On Wed, 11 May 2022 22:35:32 GMT, Weijun Wang wrote:
> Add missing OIDs for 2 secret key algorithms. These will be used when storing
> secret keys in a PKCS12 keystore. Like DES and DESede, the OIDs were
> originally defined for CBC mode cipher algorithms, they are reused here for
> key
On Wed, 11 May 2022 00:31:23 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' is
On Wed, 11 May 2022 05:52:38 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src'
On Mon, 9 May 2022 23:48:24 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' is
On Mon, 9 May 2022 23:15:40 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' is
On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote:
>> All `IntegerPolynimial`s are singletons now. Also, hand-coded
>> implementations for Ed25519 and Ed448 are removed. They were not used since
>> `FieldGen` starts generating classes for them.
>>
>> No new regression test. This is a
Hi,
I need a review of this fix to allow a read-only 'src' buffer to be used with
SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher
operation when a read-only buffer is passed. If the 'src' is read-write, there
is no effect on the current operation
The PR also
On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote:
> Only numbers from the same modular fields can be involved in arithmetic
> calculations. Add `assert` to guarantee this.
>
> Also, found one broken case and rewrote it.
Changes look good
-
Marked as reviewed by ascarpino
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
> portion of time is spent in HandshakeContext initialization, specifically in
> DisabledAlgorithmConstraints class.
>
> There are only a few instances of
On Fri, 22 Apr 2022 21:04:58 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I'd like a code review of this change to EdDSA. ed25519 and ed448 internally
> was trimming extra zeros off the end of the signature before processing. This
> can result in some verify testing failures which a
Reminder this survey ends Friday. Please fill it out if you have not.
Thanks
On 4/12/22 8:10 AM, Anthony Scarpino wrote:
Hello,
Java Cryptographic Extension (JCE) has been in Java SE for a long time
and has made incremental changes over the years. Looking forward, we
would like to know
On Fri, 22 Apr 2022 21:04:58 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I'd like a code review of this change to EdDSA. ed25519 and ed448 internally
> was trimming extra zeros off the end of the signature before processing. This
> can result in some verify testing failures which a
On Sat, 23 Apr 2022 14:39:50 GMT, Xue-Lei Andrew Fan wrote:
> Did you want to correct the verify testing so that it could
> accept trimmed signature? Or do not trimming the extra zeros
> of the signature any longer? I did not get the point from the
> patch.
The test is correct.
Perhaps a
Hi,
I'd like a code review of this change to EdDSA. ed25519 and ed448 internally
was trimming extra zeros off the end of the signature before processing. This
can result in some verify testing failures which are strict about the signature
length passed into the operation.
thanks
Tony
On Mon, 18 Apr 2022 20:43:06 GMT, Smita Kamath wrote:
>> When input length provided to the intrinsic is 8192, only 7680 bytes are
>> processed as the intrinsic operates on multiples of 768 bytes.
>> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
>> dst.put(bout, 0, PARALLEL_LEN)
On Mon, 4 Apr 2022 21:27:51 GMT, Weijun Wang wrote:
> `Thread.sleep()` seems not very precise on some systems. Update this test to
> check the current time continously.
Marked as reviewed by ascarpino (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/8098
On Mon, 18 Apr 2022 20:43:06 GMT, Smita Kamath wrote:
>> When input length provided to the intrinsic is 8192, only 7680 bytes are
>> processed as the intrinsic operates on multiples of 768 bytes.
>> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
>> dst.put(bout, 0, PARALLEL_LEN)
On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote:
> When input length provided to the intrinsic is 8192, only 7680 bytes are
> processed as the intrinsic operates on multiples of 768 bytes.
> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
> dst.put(bout, 0, PARALLEL_LEN) statement
On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote:
> When input length provided to the intrinsic is 8192, only 7680 bytes are
> processed as the intrinsic operates on multiples of 768 bytes.
> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
> dst.put(bout, 0, PARALLEL_LEN) statement
On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote:
> When input length provided to the intrinsic is 8192, only 7680 bytes are
> processed as the intrinsic operates on multiples of 768 bytes.
> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
> dst.put(bout, 0, PARALLEL_LEN) statement
Hi Sean,
Caching is an interesting idea. I've wondered for a while off and on
about how to speed it up, but hadn't come up with a solution I liked.
The complication with caching is while something like an algorithm name
only could be easy in a hashmap, it gets more complicated when you get
.
Below is a survey that we hope you can spend 5 minutes to fill out. If
you have written or maintain code that uses the JCE API, then we would
appreciate if you would complete this survey:
https://www.questionpro.com/t/AUzP7ZrFWv
The survey will be open through April 29.
Thank you,
Anthony
Thanks for all the info. We don’t have experience with JOSE or COSE, I think we
need to digest some of this data before making a future step
Not knowing this technology until you brought it up a few days ago, a few
questions i have are how is this used and how common? Would I see this used
When you say "construct and EC key", do you mean creating an EC key from
an existing set of values via PKCS8 or X509 encoding? Or are you
talking about EC key generation?
Tony
On 3/25/22 1:03 AM, Anders Rundgren wrote:
Hi Mike & the JDK crypto team,
What I'm saying is that key
On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote:
> Max, can you please help review this fix? It updates the two jarsigner tests
> which are added to the main trunk during the code review of JDK-8267319.
>
> Mach5 run succeeds.
> Thanks,
> Valerie
Marked as reviewed by ascarpino
On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote:
> It's been several years since we increased the default key sizes. Before
> shifting to PQC, NSA replaced its Suite B cryptography recommendations with
> the Commercial National Security Algorithm Suite which suggests:
>
> - SHA-384 for
On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote:
> It's been several years since we increased the default key sizes. Before
> shifting to PQC, NSA replaced its Suite B cryptography recommendations with
> the Commercial National Security Algorithm Suite which suggests:
>
> - SHA-384 for
On Tue, 1 Feb 2022 09:52:46 GMT, Boris Ulasevich wrote:
>> Background
>>
>> The goal is to improve SHA3 implementation performance as it runs up to two
>> times slower than native (OpenSSL, measured on AMD64 and AArch6464)
>> implementation. Some hardware provides SHA3 accelerators, but most
On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich
wrote:
> Background
>
> The goal is to improve SHA3 implementation performance as it runs up to two
> times slower than native (OpenSSL, measured on AMD64 and AArch6464)
> implementation. Some hardware provides SHA3 accelerators, but most
On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich
wrote:
> Background
>
> The goal is to improve SHA3 implementation performance as it runs up to two
> times slower than native (OpenSSL, measured on AMD64 and AArch6464)
> implementation. Some hardware provides SHA3 accelerators, but most
On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich
wrote:
> Background
>
> The goal is to improve SHA3 implementation performance as it runs up to two
> times slower than native (OpenSSL, measured on AMD64 and AArch6464)
> implementation. Some hardware provides SHA3 accelerators, but most
On Wed, 26 Jan 2022 18:07:24 GMT, Sebastian Stenzel
wrote:
>> Related to #411, however it turns out that for unpadded ciphers, there is no
>> need to allocate `internalOutput`, if `output` provides sufficient capacity.
>>
>> For padded ciphers, only the unpadded cleartext is expected to be
On Wed, 26 Jan 2022 10:07:01 GMT, Sebastian Stenzel
wrote:
> Related to #411, however it turns out that for unpadded ciphers, there is no
> need to allocate `internalOutput`, if `output` provides sufficient capacity.
>
> For padded ciphers, only the unpadded cleartext is expected to be copied
Hi,
I think it's a mistake. Looking at the old code I believe the if() for
cipher.save() above that was suppose to include the new byte allocation
and offset, but got missed.
Feel free to fix it if you like. Let me know if you need something.
Tony
On 1/25/22 12:06 PM, Sebastian Stenzel
On Thu, 23 Dec 2021 21:47:53 GMT, Daniel Jeliński wrote:
>> All TLS 1.3 handshakes in compatibility mode must send a non-empty SessionID
>> field. Currently TLS1.3 session resumptions are sending empty session ID.
>> This patch fixes that problem.
>>
>> All jdk_core tests passed. The newly
On Mon, 29 Nov 2021 08:42:22 GMT, Daniel Jeliński wrote:
> All TLS 1.3 handshakes in compatibility mode must send a non-empty SessionID
> field. Currently TLS1.3 session resumptions are sending empty session ID.
> This patch fixes that problem.
>
> All jdk_core tests passed. The newly added
On Wed, 1 Dec 2021 21:42:51 GMT, Valerie Peng wrote:
> PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE,
> it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the
> C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not
>
On Wed, 1 Dec 2021 21:42:51 GMT, Valerie Peng wrote:
> PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE,
> it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the
> C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not
>
On Tue, 9 Nov 2021 14:23:54 GMT, Weijun Wang wrote:
> The test was added in JDK-8237218 to confirm that Java impl is used when
> verifying a signature. It is useless now since the native implementation is
> completely removed.
Look good
-
Marked as reviewed by ascarpino
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> T
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> T
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> T
Hi,
I need a review of this change. It makes KeyPair implement Destroyable and
implements the methods to call the underlying privateKey. It also sets the
public and private key to 'final'.
The bug includes a CSR and Release Notes
CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
RN:
On Wed, 20 Oct 2021 14:47:31 GMT, Sean Mullan wrote:
>> This fix improves the exception message to better indicate when the key (and
>> not the signature algorithm) is restricted. This change also includes a few
>> other improvements:
>>
>> - The constraints checking in
On Wed, 20 Oct 2021 13:34:44 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line
>> 106:
>>
>>> 104: // "SHA-256" and "SHA256" to make the right constraint
>>> checking.
>>> 105:
>>> 106: for (Map.Entry e :
>>>
On Tue, 19 Oct 2021 20:32:21 GMT, Sean Mullan wrote:
>> This fix improves the exception message to better indicate when the key (and
>> not the signature algorithm) is restricted. This change also includes a few
>> other improvements:
>>
>> - The constraints checking in
On Tue, 19 Oct 2021 15:48:57 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line
>> 196:
>>
>>> 194: static String canonicalName(String algorithm) {
>>> 195: return CANONICAL_NAME.getOrDefault(algorithm, algorithm);
>>> 196: }
On Mon, 11 Oct 2021 23:32:26 GMT, Valerie Peng wrote:
>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes
>> support to SunPKCS11 provider?
>>
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java,
>> which is the CipherSpi impl for the native
On Mon, 11 Oct 2021 23:32:26 GMT, Valerie Peng wrote:
>> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes
>> support to SunPKCS11 provider?
>>
>> The main changes are in only one new class, i.e. P11KeyWrapCipher.java,
>> which is the CipherSpi impl for the native
On Fri, 17 Sep 2021 23:22:21 GMT, Valerie Peng wrote:
> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes
> support to SunPKCS11 provider?
>
> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which
> is the CipherSpi impl for the native PKCS11
On Fri, 17 Sep 2021 23:22:21 GMT, Valerie Peng wrote:
> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes
> support to SunPKCS11 provider?
>
> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which
> is the CipherSpi impl for the native PKCS11
On Fri, 17 Sep 2021 23:22:21 GMT, Valerie Peng wrote:
> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes
> support to SunPKCS11 provider?
>
> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, which
> is the CipherSpi impl for the native PKCS11
On Sun, 26 Sep 2021 13:27:47 GMT, Weijun Wang wrote:
> `DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE
> and should not be encoded as IMPLICIT.
>
> Please note that the parsing side (at
>
12:49 AM, David Blevins wrote:
>>>
>>>> On Sep 27, 2021, at 3:32 PM, Anthony Scarpino
>>>> wrote:
>>>
>>> On 9/27/21 2:22 PM, David Blevins wrote:
>>>> I've been putting a significant amount of work into compiling a large set
>
On 9/27/21 2:22 PM, David Blevins wrote:
I've been putting a significant amount of work into compiling a large set of
elliptic curve parameters/names/oids for an open source library and a related
closed source security product we have. We need to be able to support any of
the curves that
On Wed, 22 Sep 2021 22:48:32 GMT, Smita Kamath wrote:
>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not
>> support the new intrinsic. Tests run were crypto.full.AESGCMBench and
>> crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>>
>> The problem is
I'll run them.. Did you seem my comments? They are just code-style comments
thanks
Tony
On 9/21/21 12:43 PM, Smita Kamath wrote:
On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino
wrote:
Smita Kamath has updated the pull request incrementally with one additional
commit since the last
On Mon, 20 Sep 2021 05:16:16 GMT, Smita Kamath wrote:
>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not
>> support the new intrinsic. Tests run were crypto.full.AESGCMBench and
>> crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>>
>> The problem is
On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh wrote:
> This fix adds an EC private key range check for the scalar value to be within
> the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA
> Signature algorithms and ECDH KeyAgreement algorithms. While the SunEC
>
On Fri, 20 Aug 2021 22:43:55 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.
On Mon, 9 Aug 2021 18:08:53 GMT, Valerie Peng wrote:
>> I do not understand this comment
>
> Doesn't implGCMCrypt(...) return an int telling how much bytes it has
> processed? Then we adjust the index and remain input length with this value.
> But here we didn't save the return value which
On Fri, 6 Aug 2021 19:57:11 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>> - Updates, comment and variable cleanup
>> -
On Fri, 6 Aug 2021 20:01:00 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>> - Updates, comment and variable cleanup
>> -
On Fri, 6 Aug 2021 18:40:44 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>> - Updates, comment and variable cleanup
>> -
On Fri, 6 Aug 2021 19:44:05 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>> - Updates, comment and variable cleanup
>> -
On Fri, 6 Aug 2021 19:32:25 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>> - Updates, comment and variable cleanup
>> -
On Fri, 6 Aug 2021 19:16:39 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>> - Updates, comment and variable cleanup
>> -
On Wed, 4 Aug 2021 02:24:05 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.
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
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
>
>
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
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
>
>
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
>
>
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
>
>
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
>
>
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
On Fri, 16 Jul 2021 19:41:53 GMT, Valerie Peng wrote:
>> 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
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
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, by
On Thu, 15 Jul 2021 22:44:05 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
>
>
On Wed, 14 Jul 2021 20:21:58 GMT, djelinski
wrote:
>> ### Benchmark results
>>
>> I have benchmarked 3 cases.
>>
>> 1. The current situation.
>>
>> Benchmark
>> (cipherSuite) Mode CntScore Error Units
>>
On Fri, 2 Jul 2021 19:13:48 GMT, Anthony Scarpino wrote:
> Hi,
>
> I need a review of these new jmh tests that run AES/GCM encryption and
> decryption using byte[], heap bytebuffers, and direct bytebuffers as input
> and output buffers for single and multi-part testing.
>
On Thu, 8 Jul 2021 14:39:20 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add small.AESGCMByteBuffer and fix dataSize
>
> test/micro/org/openjdk/bench/javax/cry
> Hi,
>
> I need a review of these new jmh tests that run AES/GCM encryption and
> decryption using byte[], heap bytebuffers, and direct bytebuffers as input
> and output buffers for single and multi-part testing.
>
> thanks
>
> Tony
Anthony Scarpino h
> Hi,
>
> I need a review of these new jmh tests that run AES/GCM encryption and
> decryption using byte[], heap bytebuffers, and direct bytebuffers as input
> and output buffers for single and multi-part testing.
>
> thanks
>
> Tony
Anthony Scarpino h
On Tue, 6 Jul 2021 15:40:09 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> merge AESGCMByteArray with existing AESGCMBench
>
> test/micro/org/o
On Tue, 6 Jul 2021 15:38:20 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> merge AESGCMByteArray with existing AESGCMBench
>
> test/micro/org/openjdk/bench/java
On Tue, 6 Jul 2021 15:41:27 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> merge AESGCMByteArray with existing AESGCMBench
>
> test/micro/org/openjdk/bench/java
> Hi,
>
> I need a review of these new jmh tests that run AES/GCM encryption and
> decryption using byte[], heap bytebuffers, and direct bytebuffers as input
> and output buffers for single and multi-part testing.
>
> thanks
>
> Tony
Anthony Scarpino h
Hi,
I need a review of these new jmh tests that run AES/GCM encryption and
decryption using byte[], heap bytebuffers, and direct bytebuffers as input and
output buffers for single and multi-part testing.
thanks
Tony
-
Commit messages:
- cleanup
- initial checkin
Changes:
On Fri, 18 Jun 2021 21:27:41 GMT, Anthony Scarpino
wrote:
>> Dongbo He has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace HashSet with TreeSet
>
> test/micro/org/openjdk/bench/java/security/AlgorithmC
On Thu, 17 Jun 2021 08:16:42 GMT, Dongbo He wrote:
>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm
>> has been disabled. It is less efficient when there are more disabled
>> elements in the list, we can use Set instead of List to speed up the search.
>>
>> Patch
1 - 100 of 653 matches
Mail list logo
