On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this trivial change which replaces the usages
>> of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are
>> o
On Thu, 29 Aug 2024 19:35:25 GMT, Sean Mullan wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> pemrecord whitespace
>
> src/java.base/share/classes/java/security/PEMEn
On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino
wrote:
> Hi
>
> This change is to improve TLS 1.3 session resumption by allowing a TLS server
> to send more than one resumption ticket per connection and clients to store
> more. Resumption is a quick way to use an existing
de by changing the
> caching system used by TLS. It creates a new `CacheEntry<>` type called
> `QueueCacheEntry<>` that will store multiple values for a Map entry.
Anthony Scarpino has updated the pull request with a new target base due to a
merge or a rebase. The pull request n
On Mon, 19 Aug 2024 19:26:19 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - revert to synchronized
>> - code review changes
>
> src/java.base/share/
On Fri, 16 Aug 2024 21:07:17 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 245:
>>
>>> 243: }
>>> 244:
>>> 245: private static boolean isNullOrEmpty(Collection c) {
>>
>> This appears to not be used.
>
> Addressed in
>
On Fri, 16 Aug 2024 21:05:48 GMT, Kevin Driver wrote:
>> +1, clearer to just state "xxx does not use configuration parameters" or
>> something similar where xxx is the HKDF algorithm name.
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4
On Fri, 16 Aug 2024 21:05:32 GMT, Kevin Driver wrote:
>> Like the above method, I suggested "KDFParameters must be specified." I'm
>> fine if you choose Valerie's suggestion
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
> Pleas
On Thu, 8 Aug 2024 01:51:51 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 259:
>>
>>> 257: throw new NoSuchAlgorithmException(
>>> 258: "Received an InvalidAlgorithmParameterException. Does
>>> this "
>>> 259: + "a
On Fri, 2 Aug 2024 19:19:54 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another PR
de by changing the
> caching system used by TLS. It creates a new `CacheEntry<>` type called
> `QueueCacheEntry<>` that will store multiple values for a Map entry.
Anthony Scarpino has updated the pull request incrementally with two additional
commits since the last re
On Mon, 29 Jul 2024 17:52:52 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 21 commits:
>>
>> - Rework TLSBase for better testing
>> - Tests work
On Mon, 29 Jul 2024 17:56:44 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 21 commits:
>>
>> - Rework TLSBase for better testing
>> - Tests work
On Mon, 29 Jul 2024 17:18:59 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 21 commits:
>>
>> - Rework TLSBase for better testing
>> - Tests work
On Mon, 29 Jul 2024 16:40:21 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 21 commits:
>>
>> - Rework TLSBase for better testing
>> - Tests work
d it is subject to change in future releases
> until it is finalized.
>
> Details about this change can be seen at [PEM API
> JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>
> Thanks
>
> Tony
Anthony Scarpino has updated the pull request incrementally with one
d it is subject to change in future releases
> until it is finalized.
>
> Details about this change can be seen at [PEM API
> JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>
> Thanks
>
> Tony
Anthony Scarpino has updated the pull request incrementally with one
On Mon, 29 Jul 2024 22:58:04 GMT, Weijun Wang wrote:
>> What you are describing is why the encoder accepts EncryptedPrivateKeyInfo.
>> These more complicated configurations I left to EncryptedPrivateKeyInfo as
>> the PEM classes are not trying to replace all the functionality of
>> EncryptedP
On Fri, 26 Jul 2024 14:03:13 GMT, Weijun Wang wrote:
>> I don't see it needing any extra permissions than others.
>
> I meant if you wrap the `Security.getProperty("jdk.epkcs8.defaultAlgorithm")`
> call in a `doPrivileged` then there is no need to add a new permission here.
ok. I'll switch it
On Mon, 29 Jul 2024 23:03:02 GMT, Weijun Wang wrote:
>> I assuming you are suggesting to check when the property is used? Having an
>> error message when loading would probably be a customer call generator.
>> PEM already throws an exception if the property is not set,
>> EPKI.encryptKey() doe
On Mon, 29 Jul 2024 23:01:49 GMT, Weijun Wang wrote:
>> I do not understand this comment. Have two copies of this method in
>> PKCS8EKS and X509EKS? This sounds like duplicate code to me.
>
> Maybe this is a similar opinion on the line endings. I don't want to be too
> flexible too soon.
I d
On Thu, 25 Jul 2024 20:06:18 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.base/shar
On Fri, 26 Jul 2024 04:04:55 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 109:
>>
>>> 107: throws InvalidKeyException {
>>> 108: this(privEncoding);
>>> 109: pubKeyEncoded = pubEn
On Mon, 29 Jul 2024 16:06:07 GMT, Weijun Wang wrote:
>> I hadn't thought about an OID string value. The alternative to not using
>> returning an OID is null. I don't see a problem returning an OID, as we
>> have seen in other areas where `Key.getAlgorithm()` returns a non-crypto
>> algorithm
On Thu, 25 Jul 2024 20:48:33 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/j
On Fri, 26 Jul 2024 14:02:17 GMT, Weijun Wang wrote:
>> By the spec, probably not.. but parsers are suppose to be flexible and
>> excluding formats usually ends up is user complaints. It's no extra work to
>> allow it.
>
> Not sure if it's good to be so flexible at the beginning. You won't be
On Thu, 25 Jul 2024 22:37:22 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> test/jdk/jav
On Thu, 25 Jul 2024 20:25:18 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.
On Thu, 25 Jul 2024 20:18:20 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.
On Thu, 25 Jul 2024 20:07:55 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.base/shar
On Thu, 25 Jul 2024 20:06:18 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.base/shar
On Fri, 26 Jul 2024 14:01:26 GMT, Weijun Wang wrote:
>> if cipher is defined this is an encrypted PEMEncoder instance, so yes it's
>> important.
>> Encoding doesn't need a factory when the object already provides the DER
>> encoding.
>
> Not sure if I understand. When using encryption, user can
On Fri, 26 Jul 2024 13:57:50 GMT, Weijun Wang wrote:
>> This is something I hadn't circled back for documentation. I didn't put the
>> Standard Names Doc is not usable unfortunately. The doc says the algorithm
>> name format, but makes you look through an IETF document to find the
>> algorit
On Thu, 25 Jul 2024 14:34:51 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.b
On Tue, 23 Jul 2024 21:14:54 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/sun/security/util/Pem.java line 93:
>>
>>> 91:
>>> 92: public static final byte[] LINESEPARATOR = "\r\n"
>>> 93: .getBytes(StandardCharse
On Thu, 27 Jun 2024 18:10:37 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/sun/security/util/Cache.java line 716:
>>
>>> 714: }
>>> 715: if (entry.isValid(time)) {
>>> 716: //
On Thu, 25 Jul 2024 20:00:53 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/
On Thu, 25 Jul 2024 15:42:59 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.base/share
On Thu, 25 Jul 2024 21:02:19 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> src/java.base/shar
On Thu, 25 Jul 2024 22:41:28 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - bad test check
>> - internal PEMRecord optimization
>
> test/jdk/sun/secur
d it is subject to change in future releases
> until it is finalized.
>
> Details about this change can be seen at [PEM API
> JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>
> Thanks
>
> Tony
Anthony Scarpino has updated the pull request incrementally with two a
On Wed, 24 Jan 2024 00:01:06 GMT, Anthony Scarpino
wrote:
> Hi all,
>
> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format
> for encoding and decoding cryptographic keys and certificates. It will be
> integrated into JDK24 as a Preview Feature. P
On Fri, 10 May 2024 23:51:36 GMT, ExE Boss wrote:
>> Hi all,
>>
>> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a
>> format for encoding and decoding cryptographic keys and certificates. It
>> will be integrated into JDK24 as a Preview Feature. Preview features does
Hi all,
I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format
for encoding and decoding cryptographic keys and certificates. It will be
integrated into JDK24 as a Preview Feature. Preview features does not
permanently define the API and it is subject to change in futur
On Fri, 19 Jul 2024 17:24:04 GMT, Hai-May Chao wrote:
> 8327538: The SSLExtension class specifies incorrect values for heartbeat per
> RFC 6520 and post_handshake_auth per RFC 8446
Personally, I think no regression test is fine. There is near zero risk of the
constant being reverted.
de by changing the
> caching system used by TLS. It creates a new `CacheEntry<>` type called
> `QueueCacheEntry<>` that will store multiple values for a Map entry.
Anthony Scarpino has updated the pull request with a new target base due to a
merge or a rebase. The pull reques
On Tue, 25 Jun 2024 09:57:46 GMT, Daniel Jeliński wrote:
> Please add a test that starts multiple resumptions in parallel using the
> tickets received in the first connection. The test should verify that:
>
> * each resumption uses a different ticket
>
> * all resumptions succeed
>
>
On Mon, 24 Jun 2024 16:03:43 GMT, Anthony Scarpino
wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a qu
On Tue, 25 Jun 2024 09:14:12 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - remove frag issue
>> - Comments, remove thread, set NST default to 1,
On Tue, 25 Jun 2024 09:38:04 GMT, Daniel Jeliński wrote:
>> Anthony Scarpino has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - remove frag issue
>> - Comments, remove thread, set NST default to 1,
On Wed, 26 Jun 2024 23:01:50 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this clean backport of this test fix to jdk23.
>
> Tony
This pull request has now been integrated.
Changeset: 98fd657c
Author:Anthony Scarpino
URL:
https://git.openjdk
Hi,
I need a review of this clean backport of this test fix to jdk23.
Tony
-
Commit messages:
- Backport 4ffc5e60776353b03e9a557c39148e378b1690e2
Changes: https://git.openjdk.org/jdk/pull/19917/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19917&range=00
Issue: https:
On Mon, 24 Jun 2024 15:57:57 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review to change the a fragment buffer size miscalculation error.
> This appears when there are large handshake messages and hasn't been observed
> during application data. This was found d
On Wed, 5 Jun 2024 02:57:41 GMT, Anthony Scarpino wrote:
> Hi,
>
> I need a review for this simple change to fix a threading problem with the
> test. The server thread was not completing before the check occurred on the
> main thread. The failure showed up in windows and macos
> [JDK-8328608](https://bugs.openjdk.org/browse/JDK-8328608). There is no
> regression test as the failure hasn't shown to fail every time.
>
> thanks
>
> Tony
Anthony Scarpino has updated the pull request incrementally with one additional
commit since the last revision:
up
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Tue, 25 Jun 2024 19:44:00 GMT, Daniel Jeliński wrote:
>> I tried this and it caused a lockup in one of the tests. I see why your
>> think this is the right change, but it isn't proving out in the testing
>
> That's very interesting! Which test was it? Was it with or without #19465?
I do run
On Tue, 25 Jun 2024 08:14:10 GMT, Daniel Jeliński wrote:
>> Hi,
>>
>> I need a review to change the a fragment buffer size miscalculation error.
>> This appears when there are large handshake messages and hasn't been
>> observed during application data. This was found during testing of the
de by changing the
> caching system used by TLS. It creates a new `CacheEntry<>` type called
> `QueueCacheEntry<>` that will store multiple values for a Map entry.
Anthony Scarpino has updated the pull request incrementally with three
additional commits since the last revision:
Hi,
I need a review to change the a fragment buffer size miscalculation error.
This appears when there are large handshake messages and hasn't been observed
during application data. This was found during testing of the NewSessionTicket
change in [JDK-8328608](https://bugs.openjdk.org/browse/
On Fri, 21 Jun 2024 17:17:57 GMT, Sibabrata Sahoo wrote:
> > > Just for knowledge: If the client has multiple PSK Identity previously
> > > shared by server and client initiate a PSK resumption of type(psk_dhe_ke)
> > > and it receive a HelloRetryRequest from Server, then should client send
>
On Fri, 21 Jun 2024 09:54:34 GMT, Sibabrata Sahoo wrote:
> Just for knowledge: If the client has multiple PSK Identity previously shared
> by server and client initiate a PSK resumption of type(psk_dhe_ke) and it
> receive a HelloRetryRequest from Server, then should client send the same PSK
>
On Fri, 21 Jun 2024 08:15:42 GMT, John Jiang wrote:
> > The application calls `getSession()` from the same SSLContext of the
> > original connection.
> > ...
> > The remaining tickets sit on the client if they need them. Some
> > applications may choose to resume multiple times to download data
On Thu, 20 Jun 2024 05:15:10 GMT, John Jiang wrote:
> This enhancement allows the server side to send multiple tickets and the
> client side to store multiple ones. However, how does the client side use the
> tickets in the cache?
Yes
>
> This PR just takes the client side to find the first
On Wed, 19 Jun 2024 02:43:56 GMT, John Jiang wrote:
>> All the T13 log messages use the same format. I agree it is different from
>> the T12 log messages, but it helps distinguish the failures for different
>> protocols.
>> Though saying "session timed out" is probably better
>
> Here the sess
On Fri, 14 Jun 2024 09:14:50 GMT, Daniel Jeliński wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session t
On Tue, 18 Jun 2024 06:53:25 GMT, Andrey Turbanov wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session t
On Tue, 18 Jun 2024 07:41:06 GMT, John Jiang wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session to
>>
On Fri, 14 Jun 2024 06:23:32 GMT, Sibabrata Sahoo wrote:
> Tests added against ECDSA and ECDH NIST Test vector.
The changes look good to me.
-
Marked as reviewed by ascarpino (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19715#pullrequestreview-2126732468
On Mon, 17 Jun 2024 18:51:33 GMT, Volodymyr Paprotski wrote:
>> What causes regression in P256 "(~-8-14%)"?
>> From what I see, you re-arranged code to not execute some code
>> ("reducePositive()") when it is not needed. How this affects P256?
>
>> What causes regression in P256 "(~-8-14%)"? Fro
On Mon, 17 Jun 2024 16:28:16 GMT, Daniel Jeliński wrote:
>> Maybe the comment could use some rewording, but I tried to not write whole
>> bug report in a code comment.
>>
>> When this was first prototyped as non-threaded, the SocketException occurred
>> because multiple NSTs were sent after th
On Fri, 14 Jun 2024 18:51:02 GMT, Daniel Jeliński wrote:
>> This is a low level networking error beyond my control. All this code can
>> do is accept that the operating system has sent it a fatal error that has
>> blocked the servers ability to read data from the socket on data that was by
>>
On Fri, 14 Jun 2024 07:46:19 GMT, Daniel Jeliński wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session t
On Fri, 14 Jun 2024 01:14:55 GMT, Jamil Nimeh wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session to
>
On Fri, 14 Jun 2024 09:09:58 GMT, Daniel Jeliński wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session t
On Fri, 14 Jun 2024 16:18:07 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java line 388:
>>
>>> 386: /*
>>> 387: * This thread addresses a Windows only networking
On Fri, 14 Jun 2024 08:42:23 GMT, Daniel Jeliński wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session t
Hi
This change is to improve TLS 1.3 session resumption by allowing a TLS server
to send more than one resumption ticket per connection and clients to store
more. Resumption is a quick way to use an existing TLS session to establish
another session by avoiding the long TLS full handshake proce
On Tue, 4 Jun 2024 15:04:56 GMT, Jamil Nimeh wrote:
>> Hi
>>
>> This change is to improve TLS 1.3 session resumption by allowing a TLS
>> server to send more than one resumption ticket per connection and clients to
>> store more. Resumption is a quick way to use an existing TLS session to
>>
On Thu, 13 Jun 2024 14:01:55 GMT, Weijun Wang wrote:
> There is an error in `jarsigner` on the "This JAR contains signed entries
> that aren't signed by alias in this keystore" warning. The exit code is
> determined by
> [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2
On Thu, 13 Jun 2024 14:01:55 GMT, Weijun Wang wrote:
> There is an error in `jarsigner` on the "This JAR contains signed entries
> that aren't signed by alias in this keystore" warning. The exit code is
> determined by
> [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2
On Thu, 6 Jun 2024 14:28:25 GMT, Mark Powers wrote:
>> I have never heard that. I have always ended with a plus and I believe
>> everyone else does too if I'm not mistaken.
>
> https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-constants
>
> Probably showed up in a code review comm
On Wed, 5 Jun 2024 23:49:02 GMT, Anthony Scarpino wrote:
>> test/jdk/javax/net/ssl/templates/TLSBase.java line 246:
>>
>>> 244: void done() {
>>> 245: try {
>>> 246: t.join(5000);
>>
>> I had to increase
On Wed, 5 Jun 2024 19:57:34 GMT, Mark Powers wrote:
>> Hi,
>>
>> I need a review for this simple change to fix a threading problem with the
>> test. The server thread was not completing before the check occurred on the
>> main thread. The failure showed up in windows and macos, but not linux.
Hi,
I need a review for this simple change to fix a threading problem with the
test. The server thread was not completing before the check occurred on the
main thread. The failure showed up in windows and macos, but not linux. With
this fix, running 100 times, windows & macos showed no failur
On 5/25/24 8:22 AM, Karl Scheibelhofer wrote:
Hi Tony,
in https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore-2-pem-api
you can find a PEM keystore implementation with tests. It is based on the latest https://github.com/ascarpino/jdk/tree/pem branch.
I made these two modifications
anned next steps?
Regards, Karl
On Sat, Mar 16, 2024 at 10:36 AM Karl Scheibelhofer
<mailto:karl.scheibelhofer...@gmail.com>> wrote:
Hi Tony,
find my replies inline...
On Mon, Mar 11, 2024 at 6:13 AM Anthony Scarpino
mailto:anthony.scarp...@oracle.com>>
wrote:
On Fri, 10 May 2024 02:26:11 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8325384
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> just in case
Looks good
-
Marked as reviewed by ascarpino (Re
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
If this is an HPKE operation, shouldn't it be part of an HPKE
On Fri, 10 May 2024 00:19:32 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
On Fri, 10 May 2024 22:40:30 GMT, Weijun Wang wrote:
> One use case for this method is HPKE key export. Obviously, the exported key
> won't have algorithm name being "HPKE".
If `Cipher::init` is passed an AES SecretKey, wouldn't the `Cipher::export`
return an AES SecretKey? I don't see the ca
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
Why is the `algorithm` necessary for this new method? Couldn
On Thu, 9 May 2024 22:23:02 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Mon, 15 Apr 2024 22:12:30 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
On Sat, 13 Apr 2024 01:25:57 GMT, David Schlosnagle wrote:
> Should the buffer size be a configurable constructor parameter? This would
> allow consumers to adjust the buffer size to match their tradeoffs of memory
> vs throughput based on workload & available resources, and provide a bit of
>
On Fri, 12 Apr 2024 15:34:01 GMT, Oli Gillespie wrote:
> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>
> I have seen applications where this small buffer size significantly reduces
> throughput, and I've even seen applications which use reflection to modify
> the bu
On Fri, 12 Apr 2024 16:49:49 GMT, Anthony Scarpino
wrote:
>> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>>
>> I have seen applications where this small buffer size significantly reduces
>> throughput, and I've even seen applications w
On Fri, 12 Apr 2024 15:34:01 GMT, Oli Gillespie wrote:
> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>
> I have seen applications where this small buffer size significantly reduces
> throughput, and I've even seen applications which use reflection to modify
> the bu
On Wed, 10 Apr 2024 18:02:38 GMT, Volodymyr Paprotski wrote:
> > In `ECOperations.java`, if I understand this correctly, it is to replace
> > the existing `PointMultiplier` with montgomery-based PointMuliplier. But
> > when I look at the code, I see both are still options. If I read this
> > c
1 - 100 of 237 matches
Mail list logo
