On Fri, 22 Jan 2021 21:28:53 GMT, Weijun Wang wrote:
>> Clean up temporary byte array, char array, and keyspec around keys and
>> passwords.
>>
>> No new regression test.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> key
On Fri, 22 Jan 2021 15:43:05 GMT, Weijun Wang wrote:
>> Clean up temporary byte array, char array, and keyspec around keys and
>> passwords.
>>
>> No new regression test.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> mor
On Fri, 22 Jan 2021 14:35:46 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/PrivateKeyInfo.java line
>> 98:
>>
>>> 96:
>>> 97: public void clear() {
>>> 98: Arrays.fill(privkey, (byte)0);
>>
>> check for null just in case?
>
> `val.data.getOctetStri
On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote:
>> Clean up temporary byte array, char array, and keyspec around keys and
>> passwords.
>>
>> No new regression test.
>
> Weijun Wang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now cont
On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote:
>> Clean up temporary byte array, char array, and keyspec around keys and
>> passwords.
>>
>> No new regression test.
>
> Weijun Wang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now cont
On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote:
>> Clean up temporary byte array, char array, and keyspec around keys and
>> passwords.
>>
>> No new regression test.
>
> Weijun Wang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now cont
On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote:
>> Clean up temporary byte array, char array, and keyspec around keys and
>> passwords.
>>
>> No new regression test.
>
> Weijun Wang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now cont
On Wed, 20 Jan 2021 13:47:13 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session f
On Wed, 20 Jan 2021 13:52:26 GMT, Martin Balao wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to
>> 'P11Cipher::implDoFinal(ByteBuffer..'. Better docu
On Wed, 20 Jan 2021 13:51:56 GMT, Martin Balao wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to
>> 'P11Cipher::implDoFinal(ByteBuffer..'. Better docu
On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session f
On Fri, 15 Jan 2021 18:51:20 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session f
On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session f
On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session f
On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session f
On Mon, 18 Jan 2021 13:39:04 GMT, Claes Redestad wrote:
>> - The MD5 intrinsics added by
>> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
>> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
>> from which the MD5 intrinsic takes inspirati
On Tue, 15 Dec 2020 20:29:08 GMT, Valerie Peng wrote:
> Can someone help review this?
>
> This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11
> providers to accept RSA keys in PKCS#1 format and encoding and translate them
> to provider-specific RSA keys. Updat
On Fri, 15 Jan 2021 01:45:07 GMT, Valerie Peng wrote:
>> Marked as reviewed by weijun (Reviewer).
>
>>
>>
>> _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on
>> [security-dev](mailto:security-dev@openjdk.java.net):_
>>
&
On Fri, 15 Jan 2021 23:36:35 GMT, Claes Redestad wrote:
>> - The MD5 intrinsics added by
>> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
>> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
>> from which the MD5 intrinsic takes inspirati
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote:
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
>
On Thu, 14 Jan 2021 20:04:33 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 344:
>>
>>> 342: if (keySpec instanceof PKCS8EncodedKeySpec) {
>>> 343: return RSAPrivateCrtKeyImpl.
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote:
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
>
On Wed, 13 Jan 2021 17:07:20 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year from 2020 to 2021.
>
> Marked as reviewed by weijun (Reviewer).
1 encoded key pair.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Update to address review comments from Weijun
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1787/files
- new: https
On Wed, 13 Jan 2021 17:00:36 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year from 2020 to 2021.
>
> test/jdk/sun/security/rsa/TestKeyFa
On Tue, 12 Jan 2021 23:20:11 GMT, Martin Balao wrote:
>> I understand that the intention/design is to trigger the error condition on
>> various code paths causing the active session to be returned to pool and
>> verify if this issue is fixed or not. What I don't get is that why
>> AES/ECB/NoPa
On Wed, 13 Jan 2021 17:02:50 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year from 2020 to 2021.
>
> test/jdk/sun/security/rsa/TestKey
On Wed, 13 Jan 2021 16:23:17 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year from 2020 to 2021.
>
> src/java.base/share/classes/sun/security/r
On Wed, 13 Jan 2021 16:11:02 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year from 2020 to 2021.
>
> src/java.base/share/classes/sun/security/
On Thu, 7 Jan 2021 18:50:05 GMT, Claes Redestad wrote:
>> Removing the UUID clone cache and running the microbenchmark along with the
>> changes in #1933:
>>
>> Benchmark (size) Mode
>> CntScoreError Units
>> UUIDBench.fromType3Byte
On Tue, 12 Jan 2021 21:38:32 GMT, Martin Balao wrote:
>
>
> > For cipher impls, there are more than just P11Cipher, there are also
> > P11AEADCipher and P11RSACipher. It looks like they should be updated with
> > this defensive cancellation change unless the non-compliant NSS impl is
> > alg
1 encoded key pair.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Update copyright year from 2020 to 2021.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1787/files
- new: https://gi
1 encoded key pair.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/rebase. The pull request contains two additional commits since the
last revision:
On Tue, 15 Dec 2020 20:29:08 GMT, Valerie Peng wrote:
> Can someone help review this?
>
> This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11
> providers to accept RSA keys in PKCS#1 format and encoding and translate them
> to provider-specific RSA keys. Updat
On Fri, 8 Jan 2021 19:28:55 GMT, Martin Balao wrote:
> The P11Cipher case is different because the size of the output buffer (the
> one that may lead to a CKR_BUFFER_TOO_SMALL error) is a user input and the
> error visible to OpenJDK Java code [4] [5] [6] [7]. In addition, and contrary
> to th
On Fri, 8 Jan 2021 19:28:55 GMT, Martin Balao wrote:
>>> In summary, I believe we need changes in the OpenJDK side to properly
>>> handle CKR_BUFFER_TOO_SMALL errors when C_SignFinal or C_Sign PKCS#11
>>> functions are called from P11Signature. Even if other error types or
>>> functions such a
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote:
>> As described in JDK-8259319 [1], this fix proposal is to set proper access
>> permissions so the SunPKCS11 provider can create instances of SunJCE classes
>> when a Security Manager is installed and the fallback scheme is used.
>>
>> No r
On Fri, 8 Jan 2021 14:06:18 GMT, Martin Balao wrote:
>> So, after this PKCS11 session failed with an error, you can continue using
>> it, say give it another byte[] and it would continue to work as if the
>> earlier failed call never happened? I have not really tried it and thought
>> that thi
On Thu, 7 Jan 2021 19:50:53 GMT, Martin Balao wrote:
>> test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 122:
>>
>>> 120: cipher.doFinal(new byte[1], 0, 0);
>>> 121: } else {
>>> 122: cipher.update(new byte[1]);
>>
>> Why only calling upd
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regres
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regres
On Thu, 7 Jan 2021 21:18:22 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/security/Provider.java line 1072:
>>
>>> 1070: }
>>> 1071: public int hashCode() {
>>> 1072: return 31*31 + type.hashCode()*31 + algorithm.hashCode();
>>
>> Well, perhaps we ju
On Thu, 7 Jan 2021 21:23:19 GMT, Claes Redestad wrote:
>> By caching default constructors used in
>> `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce
>> the overhead of allocating instances in a variety of places, e.g.,
>> `MessageDigest::getInstance`, without comprom
On Thu, 7 Jan 2021 20:29:35 GMT, Martin Balao wrote:
>> test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 50:
>>
>>> 48: }
>>> 49:
>>> 50: private static class SessionLeaker {
>>
>> The term "leak/leaker" is used extensively in the test, however, this is not
>> really a le
On Thu, 7 Jan 2021 03:59:13 GMT, Claes Redestad wrote:
>> By caching default constructors used in
>> `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce
>> the overhead of allocating instances in a variety of places, e.g.,
>> `MessageDigest::getInstance`, without comprom
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regres
On Wed, 6 Jan 2021 01:27:09 GMT, Claes Redestad wrote:
>> By caching default constructors used in
>> `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce
>> the overhead of allocating instances in a variety of places, e.g.,
>> `MessageDigest::getInstance`, without comprom
On Wed, 6 Jan 2021 02:29:58 GMT, David Schlosnagle
wrote:
>> Since much of the cost is now the creation of the MessageDigest itself, I
>> added a microbenchmark to stat this overhead:
>>
>> Benchmark
>> (digesterName) Mode Cnt Score
On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote:
> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
> invalid block size), we now cancel the operation before returning the
> underlying Session to the Session Manager. This allows to use the returned
> Session for a
On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote:
> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
> invalid block size), we now cancel the operation before returning the
> underlying Session to the Session Manager. This allows to use the returned
> Session for a
On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote:
> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
> invalid block size), we now cancel the operation before returning the
> underlying Session to the Session Manager. This allows to use the returned
> Session for a
On Wed, 23 Dec 2020 19:15:48 GMT, Valerie Peng wrote:
> Max, can you help taking a look? This trivial change fixes the inconsistent
> registration properties to match the actual implementation.
>
> In addition to the DH->EC KeyFactory inconsistency, the new test finds
> ano
On Wed, 23 Dec 2020 22:35:43 GMT, Weijun Wang wrote:
>> Max, can you help taking a look? This trivial change fixes the inconsistent
>> registration properties to match the actual implementation.
>>
>> In addition to the DH->EC KeyFactory inconsistency, the new test finds
>> another MAC->Mac ty
On Wed, 23 Dec 2020 02:13:38 GMT, Valerie Peng wrote:
> Could someone please help review this trivial change - just replace
> JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
>
> Thanks,
> Valerie
This pull request has now been integrated.
Changeset: cd94606c
Aut
On Wed, 23 Dec 2020 11:58:46 GMT, Alan Bateman wrote:
>> Could someone please help review this trivial change - just replace
>> JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
>>
>> Thanks,
>> Valerie
>
> Marked as reviewed by alanb (Reviewer).
Thanks for the review.
--
Max, can you help taking a look? This trivial change fixes the inconsistent
registration properties to match the actual implementation.
In addition to the DH->EC KeyFactory inconsistency, the new test finds another
MAC->Mac typo.
Mach5 run is clean.
Thanks,
Valerie
-
Commit message
Could someone please help review this trivial change - just replace JNI_COMMIT
with 0 for all ReleasePrimitiveArrayCritical calls.
Thanks,
Valerie
-
Commit messages:
- 8258186: Replace use of JNI_COMMIT mode with mode 0
Changes: https://git.openjdk.java.net/jdk/pull/1875/files
We
On Tue, 15 Dec 2020 19:16:22 GMT, Weijun Wang wrote:
> Some array allocation is not necessary, and the content can be cleaned.
Looks good.
-
Marked as reviewed by valeriep (Reviewer).
PR: https://git.openjdk.java.net/jdk16/pull/26
Can someone help review this?
This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers
to accept RSA keys in PKCS#1 format and encoding and translate them to
provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1
encoded key pair.
Thanks,
Valerie
---
On Tue, 15 Dec 2020 19:16:22 GMT, Weijun Wang wrote:
> Some array allocation is not necessary, and the content can be cleaned.
Need a noreg-xxx label since there is no regression test.
-
PR: https://git.openjdk.java.net/jdk16/pull/26
On Mon, 7 Dec 2020 22:32:23 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Tue, 1 Dec 2020 21:51:41 GMT, Valerie Peng wrote:
> Could someone please help review this RFE? SunPKCS11 provider is updated with
> SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA
> Signature, and Hmac KeyGenerator.
>
> As SHA-3 can be used as drop
gt; CKM_ECDSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512] and
> CKM_DSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512], so I disabled those
> mechanisms in the NSS config file for regression tests. For ECDSA signatures,
> SunPKCS11 provider will fallback to CKM_ECDSA and do the digesting
On Thu, 3 Dec 2020 20:44:46 GMT, Xue-Lei Andrew Fan wrote:
> In sun.security.ssl.BaseSSLSocketImpl.java, the package of SocketChannel in
> the getChannel() spec is java.nio, which is incorrect. It should be
> java.nio.channels.
>
> Doc cleanup only, no new regression test.
>
> Bug: https://bu
On Fri, 4 Dec 2020 01:21:43 GMT, Valerie Peng wrote:
> Somehow there is a debugging statement accidentally introduced into the
> HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
> Please help review this one-line fix which removed the undesirable
> System
On Thu, 3 Dec 2020 23:28:24 GMT, Xue-Lei Andrew Fan wrote:
>
>
> Looks good to me.
Thanks for the quick review~
-
PR: https://git.openjdk.java.net/jdk/pull/1546
On Fri, 4 Dec 2020 01:57:59 GMT, Anthony Scarpino wrote:
>> Somehow there is a debugging statement accidentally introduced into the
>> HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
>> Please help review this one-line fix which removed the undesirable
>> System.out.prin
Somehow there is a debugging statement accidentally introduced into the
HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
Please help review this one-line fix which removed the undesirable
System.out.println(...) call. Did a grep on other classes under the same
package and
On Wed, 2 Dec 2020 04:58:13 GMT, Anthony Scarpino wrote:
>> The biggest part of this change is the addition of overlap protection and
>> the tests to verify it for GCM, as there were none in the open repo.
>> Additionally, GCMBufferTest had some significant changes to clean it up and
>> handl
On Wed, 2 Dec 2020 05:01:28 GMT, Anthony Scarpino wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> comments v4
Marked as reviewed by valeriep (Reviewer).
-
On Tue, 1 Dec 2020 21:51:41 GMT, Valerie Peng wrote:
> Could someone please help review this RFE? SunPKCS11 provider is updated with
> SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA
> Signature, and Hmac KeyGenerator.
>
> As SHA-3 can be used as drop
On Thu, 26 Nov 2020 02:14:40 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with five
> additional commits since the last revision:
>
> - test updates
> - test check mixup
> - Overlap protectio
On Thu, 26 Nov 2020 02:14:40 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with five
> additional commits since the last revision:
>
> - test updates
> - test check mixup
> - Overlap protectio
Could someone please help review this RFE? SunPKCS11 provider is updated with
SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA
Signature, and Hmac KeyGenerator.
As SHA-3 can be used as drop-in replacement for SHA-2 which are already
supported by SunPKCS11 provider, the
On Wed, 28 Oct 2020 21:35:25 GMT, Valerie Peng wrote:
> Could someone please help review this PKCS#11 v3.0 header files update?
>
> Changes are straight-forward as below:
> 1) Updated pkcs11.h, pkcs11f.h, pkcs11t.h to v3.0
> 2) Updated java side w/ the new constants definitions
ders. I also commented out
> some of the unused native identifiers at java side.
>
> I am adding the SHA-3 digests, signatures, and macs in a separate RFE and
> would need this one to be reviewed/integrated first.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull requ
On Fri, 27 Nov 2020 19:40:35 GMT, Weijun Wang wrote:
> There should only be one curve having type BD or PD in CurveDB.java for any
> given length. Here we keep the last one (sect163r2) so there's no behavior
> change.
>
> I tried to search on the net to see if there is a consensus on which cur
On Mon, 30 Nov 2020 21:31:18 GMT, Weijun Wang wrote:
>>>
>>>
>>> > Based on CurveDB line 141, it seems we uses the first one and discards
>>> > the rest? Are you sure we keep the last one?
>>> > Don't have answers for your questions though.
>>>
>>> Before this change both sect163k1 and sect16
On Mon, 30 Nov 2020 20:42:35 GMT, Weijun Wang wrote:
>
>
> > Based on CurveDB line 141, it seems we uses the first one and discards the
> > rest? Are you sure we keep the last one?
> > Don't have answers for your questions though.
>
> Before this change both sect163k1 and sect163r2 have "BD"
On Fri, 27 Nov 2020 19:40:35 GMT, Weijun Wang wrote:
> There should only be one curve having type BD or PD in CurveDB.java for any
> given length. Here we keep the last one (sect163r2) so there's no behavior
> change.
>
> I tried to search on the net to see if there is a consensus on which cur
On Fri, 20 Nov 2020 06:46:09 GMT, Aleksey Shipilev wrote:
>> Changes look good.
>
> Thank you, @valeriepeng. I am not sure what is the review policy for this
> code, should I wait for another reviewer?
One reviewer is good enough. You can go ahead and integrate. Thanks~
-
PR: http
On Wed, 18 Nov 2020 08:29:49 GMT, Aleksey Shipilev wrote:
> Current `sun/security/provider/SHA2` implementation is written with lots of
> small method invocations on the fastpath in `implCompress0`. Normally it does
> not matter much, because compilers are able to inline through it, and then
>
On Wed, 18 Nov 2020 05:14:11 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 560:
>>
>>> 558: System.arraycopy(buffer, 0, block, 0, blockSize);
>>> 559: buflen -= block.length;
>>> 560: retur
On Wed, 18 Nov 2020 04:28:38 GMT, Anthony Scarpino
wrote:
>> The current impl of constructBlock() seems to have code handling ibuffer >=
>> blocksize scenario. Could you fix that and also pass the input offset into
>> constructBlock() for this RFE?
>
> I redid the whole code
Sure, I will be w
On Wed, 18 Nov 2020 08:29:49 GMT, Aleksey Shipilev wrote:
> Current `sun/security/provider/SHA2` implementation is written with lots of
> small method invocations on the fastpath in `implCompress0`. Normally it does
> not matter much, because compilers are able to inline through it, and then
>
On Sat, 14 Nov 2020 00:33:35 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 818:
>>
>>> 816: // do this check here can also catch the potential integer
>>> overflow
>>> 817: // scenario for the subsequent outp
On Fri, 13 Nov 2020 22:43:17 GMT, Anthony Scarpino
wrote:
>> The assumption of this whole block here seems to be that ibuffer would not
>> contain more than a block of buffered data? If that's the case, maybe we can
>> just use 'ibuffer' instead of allocating a local 'block' and copy the data
On Sat, 14 Nov 2020 00:29:41 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 777:
>>
>>> 775: if ((src.remaining() + ((ibuffer != null) ? ibuffer.size() :
>>> 0) -
>>> 776: tagLenBytes) > dst.remaining()) {
On Mon, 16 Nov 2020 18:07:39 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/java/security/spec/MGF1ParameterSpec.java line
>> 168:
>>
>>> 166: @Override
>>> 167: public String toString() {
>>> 168: return "MGF1:" + mdName;
>>
>> do you want to insert a space after ':' ?
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Fri, 13 Nov 2020 20:11:45 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comment update
>> Major change to test to detect corruption with in
On Thu, 12 Nov 2020 16:34:30 GMT, Anthony Scarpino
wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Code review comment update
> Major change to test to detec
On Mon, 2 Nov 2020 22:30:45 GMT, Anthony Scarpino wrote:
>>> * It was my expectation that checkOutputCapacity() is making sure all
>>> the inOfs ==<> outOfs are going to work. Does that not catch all cases?
>> checkOutputCapacity() as the name has, only changes that the output buffer
>> is
501 - 600 of 1381 matches
Mail list logo
