the abstract keyword is
> present.
>
> BTW, I also added Override tags and make a few other cleanup, for example
> adding the 'final' keywords.
>
> Thanks,
> Xuelei
Xue-Lei Andrew Fan has updated the pull request with a new target base due to a
merge or a rebase. The increme
On Thu, 10 Nov 2022 00:23:47 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> Please review this simple fix for readability.
>>
>> In the AES cipher implementation, the AESCipher class is defined as
>> abstract. As is not necessary as there is no abstract method in this class.
>> Code reader may
On Wed, 9 Nov 2022 16:38:38 GMT, Xue-Lei Andrew Fan wrote:
> > The way I see it is this: as limbs are 64-bit wide, the only place where
> > they can possibly overflow (during the computations they are used for) is
> > the multiplication (including multiply by int and squ
On Tue, 8 Nov 2022 18:38:59 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the micro-benchmark code reviewed for EC signature algorithms?
> The benchmarking now is focused on EC algorithms, more algorithms (e.g.,
> RSA/PSS based) may be added later if needed.
>
On Fri, 16 Sep 2022 00:27:55 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this simple fix for readability.
>
> In the AES cipher implementation, the AESCipher class is defined as abstract.
> As is not necessary as there is no abstract method in this class. Code
On Wed, 9 Nov 2022 14:27:26 GMT, Ferenc Rakoczi wrote:
> The way I see it is this: as limbs are 64-bit wide, the only place where they
> can possibly overflow (during the computations they are used for) is the
> multiplication (including multiply by int and squaring). So I would first try
>
On Tue, 8 Nov 2022 22:07:35 GMT, Sean Mullan wrote:
> > > Unfortunately, I only have author status and can only comment.
> >
> >
> > I think OpenJDK Author can approve as well. I just need to get another
> > Reviewer approval before integration.
>
> For a CSR, I believe that is true. But you
On Tue, 8 Nov 2022 21:18:20 GMT, Mark Powers wrote:
> Unfortunately, I only have author status and can only comment.
I think OpenJDK Author can approve as well. I just need to get another
Reviewer approval before integration.
-
PR: https://git.openjdk.org/jdk/pull/9776
On Tue, 8 Nov 2022 16:51:24 GMT, Mark Powers wrote:
> I'll look at your CSR this morning. Make sure your SSLParameters additions
> look correct with JavaDoc. I always forget that step.
Thank you for the suggestion. I double checked the JavaDoc. It looks good to
me.
Please feel free to add
On Tue, 8 Nov 2022 20:10:40 GMT, Weijun Wang wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use standard names
>
> test/micro/org/openjdk/bench/java/security/Signatures.
> Hi,
>
> May I have the micro-benchmark code reviewed for EC signature algorithms?
> The benchmarking now is focused on EC algorithms, more algorithms (e.g.,
> RSA/PSS based) may be added later if needed.
>
> Thanks,
> Xuelei
Xue-Lei Andrew Fan has updated the pu
Hi,
May I have the micro-benchmark code reviewed for EC signature algorithms? The
benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS
based) may be added later if needed.
Thanks,
Xuelei
-
Commit messages:
- 8296591: Signature benchmark
Changes:
On Tue, 8 Nov 2022 10:01:47 GMT, Ryan Wallace wrote:
>> SubjectCodeSource is no longer used, Class should be deleted and all
>> references updated
>
> Ryan Wallace has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated
On Mon, 7 Nov 2022 23:24:39 GMT, Mark Powers wrote:
>> Xue-Lei Andrew Fan has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains four commits:
>>
>> - Merge
>> - Merge
>> - add test cases
>>
wse/JDK-8291975
>
> This is an effort similar to [JDK-8280494: "(D)TLS signature
> schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
Xue-Lei Andrew Fan has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commi
On Thu, 13 Oct 2022 18:15:30 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed? With this update, the result will be
>> reduced if required in EC limbs operations in the JDK implementation.
>>
>> In the current implementation, t
On Tue, 9 Aug 2022 15:30:57 GMT, Xue-Lei Andrew Fan wrote:
>> This update is to support key exchange named groups customization for
>> individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bug
On Mon, 7 Nov 2022 17:43:42 GMT, Rajan Halade wrote:
> Test is updated to set validation date inside PKIXParameters to June 01, 2022.
Looks good to me.
-
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.org/jdk/pull/11026
On Thu, 3 Nov 2022 16:32:13 GMT, Ferenc Rakoczi wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> typo correction
>
> Thanks!
@ferakocz All good suggestions to me. Thank you
> Signatures.sign Ed25519 512 thrpt 15 1189.044 ± 5.370
> ops/s
> Signatures.sign Ed25519 2048 thrpt 15 1182.833 ± 13.186
> ops/s
> Signatures.sign Ed2551916384 thrpt 15 1099.599 ± 3.932
> ops/s
> Signatures.sign
On Thu, 3 Nov 2022 16:51:47 GMT, Mark Powers wrote:
> Is this improvement also derived from the paper by Renes, Costello, and
> Batina?
Not really. The idea is an improvement of the traditional double and addition
formulas [1] for EC algorithms, by using interleaved multiplication [2]. In
On Thu, 3 Nov 2022 14:59:59 GMT, Sean Mullan wrote:
> This change will disable TLS_ECDH_* cipher suites by default. These cipher
> suites do not preserve forward secrecy and are rarely used in practice. See
> the CSR for more details and rationale.
>
> Users will still be able to enable the
oreError Units
> Signatures.sign 64 thrpt 15 1486.764 ± 17.908 ops/s
> Signatures.sign 512 thrpt 15 1494.801 ± 14.072 ops/s
> Signatures.sign 2048 thrpt 15 1500.170 ± 6.998 ops/s
> Signatures.sign 16384 thrpt 15 1
On Wed, 2 Nov 2022 14:35:20 GMT, Ferenc Rakoczi wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> more improvement
>
> src/java.base/share/classes/sun/security/util/math/I
On Wed, 2 Nov 2022 14:44:30 GMT, Ferenc Rakoczi wrote:
> > > ... you only have one chance to measure, so cannot average out noise ...
> >
> >
> > There are cases that one chance is enough to place an attack. We normally
> > don't discuss vulnerability details in public, please send me an
On Wed, 2 Nov 2022 04:37:44 GMT, Mark Powers wrote:
> tier1 and tier2 tests all pass
Thank you very much, @mcpowers! Please let me know if you need more time for
the review.
-
PR: https://git.openjdk.org/jdk/pull/10893
On Tue, 1 Nov 2022 22:59:14 GMT, Mark Powers wrote:
> > Anyone from Oracle can help me to run Mach5 testing, just in case I missed
> > something?
>
> Do you have any specific mach5 tests in mind?
Please have tier 1 and tier2 covered. Thanks!
-
PR:
On Tue, 1 Nov 2022 17:43:22 GMT, Mark Powers wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove tailing whitespaces
>
> src/jdk.crypto.ec/share/classes/sun/security
> Signatures.sign Ed25519 512 thrpt 15 1189.044 ± 5.370
> ops/s
> Signatures.sign Ed25519 2048 thrpt 15 1182.833 ± 13.186
> ops/s
> Signatures.sign Ed2551916384 thrpt 15 1099.599 ± 3.932
> ops/s
> Signatures.sign
On Mon, 31 Oct 2022 20:29:23 GMT, Sean Mullan wrote:
> Can you please wait a few days on integrating this? I would like @ferakocz
> and/or @mcpowers to also look at this.
Sure. I'd appreciate if the review could be done by the end of this week.
-
PR:
On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The EC point multiplication for secp256r1 could be improved for better
>> performance, by using more efficient algorithm and pre-computatio
On Mon, 31 Oct 2022 17:19:21 GMT, Xue-Lei Andrew Fan wrote:
>>> BigInteger exponentiation time also depends on also depends on the base;
>>> quick benchmark: `BigInteger.ONE.modPow(mod.subtract(BigInteger.TWO), mod)`
>>> vs `BigInteger.TWO.modPow(mod.su
On Mon, 10 Oct 2022 08:21:57 GMT, Ferenc Rakoczi wrote:
> ... you only have one chance to measure, so cannot average out noise ...
There are cases that one chance is enough to place an attack. We normally
don't discuss vulnerability details in public, please send me an email in
private if
On Fri, 28 Oct 2022 22:04:39 GMT, Weijun Wang wrote:
>> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode`
>> interface methods are modified from `OutputStream` to `DerOutputStream`. All
>> implementations are modified the same way.
>>
>> `OutputStream` is still used by
>>
On Sat, 8 Oct 2022 15:34:57 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this patch reviewed?
>>
>> This is one of a few steps to improve the EC performance. The multiplicative
>> inverse implementation could be improved for better perfor
On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The EC point multiplication for secp256r1 could be improved for better
>> performance, by using more efficient algorithm and pre-computatio
On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8293412
I think it is a good clean up so that the default one get used in testing.
-
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10716
> Signatures.sign Ed25519 512 thrpt 15 1189.044 ± 5.370
> ops/s
> Signatures.sign Ed25519 2048 thrpt 15 1182.833 ± 13.186
> ops/s
> Signatures.sign Ed2551916384 thrpt 15 1099.599 ± 3.932
> ops/s
>
On Fri, 28 Oct 2022 09:53:56 GMT, Daniel Jeliński wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add missed update to use ECPoint directly
>
> src/jdk.crypto.ec
> Signatures.sign Ed25519 512 thrpt 15 1189.044 ± 5.370
> ops/s
> Signatures.sign Ed25519 2048 thrpt 15 1182.833 ± 13.186
> ops/s
> Signatures.sign Ed2551916384 thrpt 15 1099.599 ± 3.932
> ops/s
> Signatures.sign
On Fri, 28 Oct 2022 17:00:12 GMT, Sean Mullan wrote:
> Disable DTLS 1.0 by default. This version of DTLS has weakened over time and
> lacks support for stronger cipher suites. DTLS 1.0 correlates with version
> 1.1 of TLS which has already been disabled by default in JDK 16. The IETF has
>
On Thu, 27 Oct 2022 22:10:15 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed?
>
> The EC point multiplication for secp256r1 could be improved for better
> performance, by using more efficient algorithm and pre-computation.
> Improvement for oth
Hi,
May I have this update reviewed?
The EC point multiplication for secp256r1 could be improved for better
performance, by using more efficient algorithm and pre-computation.
Improvement for other curves are similar, but will be addressed in separated
PRs.
The basic idea is using
On Thu, 27 Oct 2022 14:21:19 GMT, Sean Mullan wrote:
> For timestamp nonces, change the PKCS7 code to use the default SecureRandom
> PRNG (which varies depending on the OS), instead of SHA1PRNG.
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10883
On Tue, 25 Oct 2022 17:56:10 GMT, Xue-Lei Andrew Fan wrote:
>> Thanks Tony!
>
> @mcpowers Did you want to update line line 203-207 as well? It might be safe
> to remove the current getID(byte[]) method. If the parameter is null, there
> is an NPE (unexpected); otherwi
On Tue, 25 Oct 2022 15:57:56 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8293093
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add getIDNullSafe
Marked as reviewed by xuelei (Reviewer).
-
On Tue, 25 Oct 2022 17:49:49 GMT, Mark Powers wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add getIDNullSafe
>
> Thanks Tony!
@mcpowers Did you want to update line line 203-207 as well? It might be safe
to
On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8293093
There are some other places, for example in updatePkey(), that use cka_id. Did
you have a chance to check if NPE is possible there as well?
-
PR:
gt; ops/s
> Signatures.sign Ed25519 2048 thrpt 15 1144.818 ± 5.768
> ops/s
> Signatures.sign Ed2551916384 thrpt 15 1081.061 ± 8.283
> ops/s
> Signatures.signEd448 64 thrpt 15 321.304 ± 0.638
> ops/s
> Signat
nits
> KeyPairGenerators.keyPairGen thrpt 15 1367.162 ± 50.322 ops/s
>
>
> with improved limbs (from 10 to 9):
>
> Benchmark Mode Cnt ScoreError Units
> KeyPairGenerators.keyPairGen thrpt 15 1713.097 ± 8.003 ops/s
>
> If consider
nits
> KeyPairGenerators.keyPairGen thrpt 15 1367.162 ± 50.322 ops/s
>
>
> with improved limbs (from 10 to 9):
>
> Benchmark Mode Cnt ScoreError Units
> KeyPairGenerators.keyPairGen thrpt 15 1713.097 ± 8.003 ops/s
>
> If consider
On Wed, 12 Oct 2022 12:43:09 GMT, Daniel Jeliński wrote:
>> This patch rewrites some BigInteger and curve point operations used in EC
>> calculations:
>> - coefficient * 2^power is equivalent to coefficient << power
>> - number mod 2^n is equivalent to number & (2^n-1)
>> - pair of
On Wed, 12 Oct 2022 12:31:20 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java
>> line 332:
>>
>>> 330:
>>> 331: protected void setLimbsValuePositive(BigInteger v, long[] limbs) {
>>> 332: assert bitsPerLimb < 32;
>>
On Tue, 11 Oct 2022 18:53:54 GMT, Daniel Jeliński wrote:
>> This patch fixes the issue where a thread doing SSLSocket.close() could
>> destroy the read cipher while it was used by another thread doing
>> SSLSocket.read().
>>
>> The reported issue was triggered by SSLSocket.close() calling
>>
On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeliński wrote:
> This patch rewrites some BigInteger and curve point operations used in EC
> calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP
On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the code clean up reviewed?
>
> There is a lot of computation in AESCrypt class load, which could be avoid by
> using the computation result directly. The computation takes 6.971875
> milli
On Tue, 11 Oct 2022 00:05:05 GMT, Valerie Peng wrote:
> Mach5 result looks ok. There is one unexpected test failure but it seems
> unrelated
> (https://mach5.us.oracle.com:10060/api/v1/results/vpeng-jdkOh-20221010-1957-37280778-open_test_lib-test-linux-x64-122-1665432715-16/log)
> . So, it
On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed? With this update, the result will be always
> reduced in EC limbs addition and subtraction operations in the JDK
> implementation.
>
> In the current implementation,
On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed? With this update, the result will be always
> reduced in EC limbs addition and subtraction operations in the JDK
> implementation.
>
> In the current implementation,
On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computa
uted result explicitly. The
> existing regression and inter-op tests should be sufficient to ensure that
> the tables are correctly copied from the dumping of the old computation code
> results.
>
> Except that, I also cleaned up some code warnings from the IDE I used.
>
On Mon, 10 Oct 2022 16:46:25 GMT, Mark Powers wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a MacOS M1
On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed? With this update, the result will be always
> reduced in EC limbs addition and subtraction operations in the JDK
> implementation.
>
> In the current implementation,
Hi,
May I have this update reviewed? With this update, the result will be always
reduced in EC limbs addition and subtraction operations in the JDK
implementation.
In the current implementation, the EC limbs addition and subtraction result is
not reduced before the value is returned. This
On Thu, 6 Oct 2022 19:35:09 GMT, Daniel Jeliński wrote:
> could you also try using precomputed powers of t between 0-15? similar to
> what we do in
>
oreError Units
> Signatures.sign 64 thrpt 15 1486.764 ± 17.908 ops/s
> Signatures.sign 512 thrpt 15 1494.801 ± 14.072 ops/s
> Signatures.sign 2048 thrpt 15 1500.170 ± 6.998 ops/s
> Signatures.sign 16384 thrpt 15 1
On Thu, 6 Oct 2022 18:33:51 GMT, Xue-Lei Andrew Fan wrote:
>> It seems to me the scalar multiplication enhancement should be done first,
>> or maybe integrated with this fix.
>> Do you have a bug number for the scalar multiplication enhancement?
>
>> It seems to m
On Thu, 6 Oct 2022 16:11:17 GMT, Mark Powers wrote:
> It seems to me the scalar multiplication enhancement should be done first, or
> maybe integrated with this fix. Do you have a bug number for the scalar
> multiplication enhancement?
I did not file the scalar multiplication enhancement in
On Wed, 5 Oct 2022 17:44:39 GMT, Daniel Fuchs wrote:
> I wonder if it would be worthwhile to have a static method that could be
> called in an assert (or in a test using --patch-module) to verify that the
> various statically initialized arrays are the same than those that would have
> been
16384 thrpt 15 1437.364 ± 8.291 ops/s
>
>
> It looks like the performance improvement is no significant enough for now.
> But it may be 2+ times more in numbers when the scalar multiplication
> implementation is improved in a follow-up enhancement in another pull request.
>
> En
On Mon, 3 Oct 2022 19:18:20 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this simple code clean-up patch reviewed?
>
> In the AES cipher implementation, the override of engineDoFinal() method in
> the following code is not necessary as it only calls super. The thro
On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeliński wrote:
> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
>
> Invocations of
>
Hi,
May I have this patch reviewed?
This is one of a few steps to improve the EC performance. The multiplicative
inverse implementation could be improved for better performance.
For secp256r1 prime p, the current multiplicative inverse impl needs 256
square and 128 multiplication. With the
On Tue, 4 Oct 2022 17:06:53 GMT, Valerie Peng wrote:
> Thanks for the clean up.
Thank you for the review.
-
PR: https://git.openjdk.org/jdk/pull/10545
Hi,
May I have this simple code clean-up patch reviewed?
In the AES cipher implementation, the override of engineDoFinal() method in the
following code is not necessary as it only calls super. The throws
descriptions are missed in the method description. I may be better to remove
this
On Wed, 28 Sep 2022 08:12:09 GMT, Ferenc Rakoczi wrote:
>> Hi,
>>
>> In the message digest implementation, for example SHA256, in JDK, two
>> bitwise operations could be improved with equivalent arithmetic, and then
>> the number bitwise operations could be reduced accordingly. Specifically
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Sat, 24 Sep 2022 08:17:56 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> Please review this performance improvement for Secp256R1 implementation in
>> OpenJDK. With this update, there is an about 20% performance improvement
>> for Secp256R1 key generation and si
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
Hi,
Please review this performance improvement for Secp256R1 implementation in
OpenJDK. With this update, there is an about 20% performance improvement for
Secp256R1 key generation and signature.
Basically, 256 bits EC curves could use 9 integer limbs for the computation.
The current
On Wed, 21 Sep 2022 18:29:08 GMT, Aleksey Shipilev wrote:
> Maybe older X86 and AArch64 are our targets, since it is not guaranteed to
> have SHA hardware intrinsics?
Yes, the platforms that do not support SHA intrinsics are the targets. If I
read the OpenJDK CPU code correctly, RISC-V and
On Wed, 21 Sep 2022 12:06:31 GMT, Aleksey Shipilev wrote:
>> Hi,
>>
>> In the message digest implementation, for example SHA256, in JDK, two
>> bitwise operations could be improved with equivalent arithmetic, and then
>> the number bitwise operations could be reduced accordingly.
Hi,
In the message digest implementation, for example SHA256, in JDK, two bitwise
operations could be improved with equivalent arithmetic, and then the number
bitwise operations could be reduced accordingly. Specifically
"(x and y) xor ((complement x) and z)" could be replaced with the
On Wed, 14 Sep 2022 05:58:10 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this simple code cleanup.
>
> The following checking for key in the makeSessionKey() method is redundant as
> it the same checking has been performance before calling the method.
>
>
On Thu, 15 Sep 2022 05:21:52 GMT, Daniel Jeliński wrote:
>> Speaking of MessageDigest.isEqual, we don't need constant time comparison
>> here. We could use Arrays.equals for some extra performance.
>
> Actually, never mind that. We need constant time comparison to avoid leaking
> information
On Wed, 14 Sep 2022 18:14:21 GMT, Xue-Lei Andrew Fan wrote:
>> Actually, NM, init still has to call MessageDigest.isEqual so eliminating
>> keys of invalid length before that is probably more efficient.
>
> Good point. Modified to use less checking.
>
> If the ke
On Wed, 14 Sep 2022 17:48:22 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 605:
>>
>>> 603: */
>>> 604: private void makeSessionKey(byte[] k) throws InvalidKeyException {
>>> 605: int ROUNDS = getRounds(k.length);
>>
InvalidKeyException("Empty key");
> }
> if (!isKeySizeValid(k.length)) {
> throw new InvalidKeyException("Invalid AES key length: " +
>k.length + " bytes");
> }
>
>
> N
On Wed, 14 Sep 2022 13:25:41 GMT, Sean Mullan wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - remove unused throws in comment
>> - remove unused throws
>
> src/ja
InvalidKeyException("Empty key");
> }
> if (!isKeySizeValid(k.length)) {
> throw new InvalidKeyException("Invalid AES key length: " +
>k.length + " bytes");
> }
>
>
> N
On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey wrote:
> Ensure that security properties are only overridden if the override security
> properties file exists.
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.
Looks
Hi,
Please review this simple code cleanup.
The following checking for key in the makeSessionKey() method is redundant as
it the same checking has been performance before calling the method.
if (k == null) {
throw new InvalidKeyException("Empty key");
}
if
On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey wrote:
> Ensure that security properties are only overridden if the override security
> properties file exists.
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.
Is it
On Tue, 9 Aug 2022 15:30:57 GMT, Xue-Lei Andrew Fan wrote:
>> This update is to support key exchange named groups customization for
>> individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bug
On Fri, 26 Aug 2022 12:03:33 GMT, Sean Coffey wrote:
> ... on your "preference of client or server suites" data point question
It is not expected to break the connection by changing the preference even
there are multiple key exchange algs. There may be bugs, but did you see
failures
On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote:
> This fix adds Certigna root CA to cacerts trust store.
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10030
On Thu, 25 Aug 2022 21:03:35 GMT, Xue-Lei Andrew Fan wrote:
>> @XueleiFan - I think it's fair to say that the current "no cipher suites in
>> common" exception message is misleading for some scenarios. If not
>> misleading, it's ambiguous. You could be dealing with
201 - 300 of 337 matches
Mail list logo
