On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 22:59:52 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Thu, 10 Nov 2022 22:41:31 GMT, Volodymyr Paprotski wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 249:
>>
>>> 247: @ForceInline
>>> 248: @IntrinsicCandidate
>>> 249: private void processMultipleBlocks(byte[] input, int offset, int
>>> length, lon
On Fri, 11 Nov 2022 01:14:05 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Fri, 11 Nov 2022 01:14:05 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Fri, 11 Nov 2022 01:10:54 GMT, Mark Powers wrote:
>> test/jdk/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java line
>> 29:
>>
>>> 27: * @summary NativeSeedGenerator is making 8192 byte read requests from
>>> 28: * entropy pool on each init.
>>> 29: * @run main/othe
On Fri, 11 Nov 2022 01:14:05 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and
> java.
> - Would like to add an `I
On Mon, 31 Oct 2022 07:48:19 GMT, Daniel Jeliński wrote:
>> https://bugs.openjdk.org/browse/JDK-8293412
>
> test/jdk/java/security/SecureRandom/ApiTest.java line 56:
>
>> 54:
>> 55: public static void main(String[] args) throws Exception {
>> 56: System.setProperty("java.security.eg
On Wed, 9 Nov 2022 22:44:59 GMT, Weijun Wang wrote:
>> `EDIPartyName` should not have a null `partyName`.
>>
>> Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array.
>> Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null
>> content. This would lead to a
On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin wrote:
> Could I have a review of PR that fixes so unsigned numbers are printed
> correctly in the jfr tool.
>
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
>
> Thanks
> Erik
This pull request has been closed without being integrat
> Could I have a review of PR that fixes so unsigned numbers are printed
> correctly in the jfr tool.
>
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
>
> Thanks
> Erik
Erik Gahlin has updated the pull request with a new target base due to a merge
or a rebase. The pull request
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and
> java.
> - Would like to add an `I
On Thu, 10 Nov 2022 22:03:24 GMT, Sandhya Viswanathan
wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix windows and 32b linux builds
>
> src/hotspot/share/opto/library_call.cpp line 6981:
>
>> 6979:
>>
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and
> java.
> - Would like to add an `I
On Tue, 8 Nov 2022 22:42:05 GMT, Weijun Wang wrote:
> - All `CertAttrSet` child classes now implement `DerEncoder`
> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate
> methods are removed
> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need
On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 wrote:
> did you changed 420 files ?
I ran a custom utility that edited these files, yes.
-
PR: https://git.openjdk.org/jdk/pull/11073
On Thu, 10 Nov 2022 01:22:04 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman wrote:
> I'm trying to understand what "fix-ups" will be needed if the automated patch
> is applied. In some cases, it looks the same spec will be linked from "See
> also" and "External Specifications", e.g.
> http://cr.openjdk.java.net/~jjg/82965
On Thu, 10 Nov 2022 20:41:24 GMT, Sean Mullan wrote:
> Since this test is named "Signatures", I have filed a follow-on issue to
> enhance this benchmark to support non-EC signatures:
> https://bugs.openjdk.org/browse/JDK-8296818. I would like to have that in the
> system, so that we don't forg
On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo wrote:
> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
If you want to instead do some general cleanup in this class for JDK 20, you
could instead remove this method and several other unused methods from
`JarVerifier`.
-
On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote:
> > When referencing an RFC, it might be good to keep the RFC number in the
> > text link. For instance I see that java.net.URL now has this:
>
> I agree and also to add that some RFCs have commas in their titles, the same
> separator used
On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote:
> Hi Jon,
>
> When referencing an RFC, it might be good to keep the RFC number in the text
> link. For instance I see that java.net.URL now has this:
>
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
>
> Extern
On Thu, 10 Nov 2022 20:51:40 GMT, Weijun Wang wrote:
>> - All `CertAttrSet` child classes now implement `DerEncoder`
>> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate
>> methods are removed
>> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no
On Thu, 10 Nov 2022 15:33:26 GMT, Sean Mullan wrote:
>> 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 changes
>> brought in by the merge/rebase. The pull request contains seven additional
>> commits
On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote:
> When referencing an RFC, it might be good to keep the RFC number in the text
> link.
+1.
-
PR: https://git.openjdk.org/jdk/pull/11073
On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo wrote:
> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
I'm not sure. You can probably ask on jdk8u-...@openjdk.java.net.
-
PR: https://git.openjdk.org/jdk/pull/11072
> - All `CertAttrSet` child classes now implement `DerEncoder`
> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate
> methods are removed
> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need
> to implement it
> - `X509CertImpl::encode(OutputStre
On Thu, 10 Nov 2022 20:24:31 GMT, Sean Mullan wrote:
>> - All `CertAttrSet` child classes now implement `DerEncoder`
>> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate
>> methods are removed
>> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no
On Tue, 8 Nov 2022 20:40:49 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.
>>
>> Thanks,
>> Xuele
On Thu, 10 Nov 2022 20:11:46 GMT, Jamil Nimeh wrote:
>> This PR delivers ChaCha20 intrinsics that accelerate the core block function
>> that generates key stream from the key, counter and nonce. Intrinsics have
>> been written for the following platforms and instruction sets:
>>
>> - x86_64:
On Tue, 8 Nov 2022 22:42:05 GMT, Weijun Wang wrote:
> - All `CertAttrSet` child classes now implement `DerEncoder`
> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate
> methods are removed
> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need
On Thu, 10 Nov 2022 20:12:30 GMT, Jamil Nimeh wrote:
>> Jamil Nimeh has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> replace hi/lo word shuffles and left-right shift/or operations for vpshufd
>> on byte-aligned rotations
>
> using vpshuf
> This PR delivers ChaCha20 intrinsics that accelerate the core block function
> that generates key stream from the key, counter and nonce. Intrinsics have
> been written for the following platforms and instruction sets:
>
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the
On Thu, 10 Nov 2022 17:59:44 GMT, Weijun Wang wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public
On Thu, 10 Nov 2022 15:27:52 GMT, Weijun Wang wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public
Hi,
May I have the micro-benchmark code reviewed for EC key pair generation
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:
- 8296809: KeyPairGenerator benchmark
C
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
> reader may try to
On Thu, 10 Nov 2022 02:43:21 GMT, Weijun Wang wrote:
>> One `PKCS9Attribute` can be created but cannot be encoded. Since the
>> `SigningCertificateInfo::parse` method has not fully parsed the data
>> (`PolicyInformation` is left out), this code change add the encoding itself
>> as a field to t
On Thu, 10 Nov 2022 16:41:13 GMT, Kevin Driver wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address xuelei's comments
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
> 187:
>
>> 1
> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
> remember to initialize the params. This is unfortunate but since this is a
> public API, I hesitate to make a change.
>
> Instead, this code c
On Thu, 10 Nov 2022 17:59:44 GMT, Weijun Wang wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public
On Thu, 10 Nov 2022 17:07:45 GMT, Kevin Driver wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address xuelei's comments
>
> test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetAlgName.java line 72:
>
>> 70:
On Thu, 10 Nov 2022 15:27:52 GMT, Weijun Wang wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 16:05:46 GMT, Weijun Wang wrote:
> The method is not called since JDK 9, and that's why I set Affected Version/s
> to 8-pool. We don't intend to fix this in the current release.
Oh. Could you tell me where I should submit this PR? `jdk8u`?
-
PR: https://git.ope
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo wrote:
> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
The method is not called since JDK 9, and that's why I set Affected Version/s
to 8-pool. We don't intend to fix this in the current release.
-
PR: https://g
On Thu, 10 Nov 2022 15:33:26 GMT, Sean Mullan wrote:
>> 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 changes
>> brought in by the merge/rebase. The pull request contains seven additional
>> commits
> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
> remember to initialize the params. This is unfortunate but since this is a
> public API, I hesitate to make a change.
>
> Instead, this code c
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 cha
On Thu, 10 Nov 2022 05:49:12 GMT, Xue-Lei Andrew Fan wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>>
On Thu, 10 Nov 2022 14:43:00 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
>> 199:
>>
>>> 197: if (tmp != null) {
>>> 198: this.algid = tmp;
>>> 199: this.params = null;
>>
>> There is a getAlgParameters()
On Thu, 10 Nov 2022 06:15:27 GMT, Xue-Lei Andrew Fan wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>>
On Thu, 10 Nov 2022 06:14:48 GMT, Xue-Lei Andrew Fan wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>>
On Thu, 10 Nov 2022 05:42:27 GMT, Xue-Lei Andrew Fan wrote:
>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
>> 423:
>>
>>> 421: // wrap everything into a SEQUENCE
>>> 422: out.write(DerValue.tag_Sequence, tmp);
>>> 423: return ou
Daniel et al -
Please avoid using ietf.org as the cite location for RFCs
The preferred cite for RFCs is generally via
www.rfc-editor.org/info/rfc - that will get you to the info
page, but with links to pdf, html, and a clean .txt.
Cf https://www.rfc-editor.org/info/rfc4180 - "Cite this RFC"
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote:
> When referencing an RFC, it might be good to keep the RFC number in the text
> link. For instance I see that java.net.URL now has this:
I agree and also to add that some RFCs have commas in their titles, the same
separator used when there
61 matches
Mail list logo
