Thanks,
Are there also plans to add X25519MLKEM768, SecP256r1MLKEM768, and
SecP384r1MLKEM1024 hybrid key agreements from
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/?
>From what I know Google, Firefox, CloudFlare, and OpenSSL have all
implemented the draft, and there may not be ma
On Wed, 21 May 2025 00:18:14 GMT, Artur Barashev wrote:
>> The stateless session ticket is included in the ClientHello message, either
>> in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key
>> extension (TLS1.3). With the current construction, the ticket is often the
>> la
On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
>> approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally
On Tue, 20 May 2025 13:38:11 GMT, Alan Bateman wrote:
> A question for folks on security-dev. Are there tests for Cipher.doFinal,
> CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer
> obtained from a memory segment?
I don't find any. We'd have to update them to cover the m
On Tue, 20 May 2025 23:51:15 GMT, Leonid Mesnik wrote:
> I haven't find answer an my question about testing. How this fix is tested?
The change in the file test/jdk/sun/security/provider/acvp/Launcher.java in PR
https://github.com/openjdk/jdk/pull/23860/files covers this as well.
-
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
> respectively.
>
> CSR is underway.
>
> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
> API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net
> jck:api/javax_security jck:ap
On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
> The stateless session ticket is included in the ClientHello message, either
> in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key
> extension (TLS1.3). With the current construction, the ticket is often the
> largest contributor to the ClientHello message size. For example
On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
>> approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
> respectively.
>
> CSR is underway.
>
> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
> API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net
> jck:api/javax_security jck:ap
> The stateless session ticket is included in the ClientHello message, either
> in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key
> extension (TLS1.3). With the current construction, the ticket is often the
> largest contributor to the ClientHello message size. For example
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
> respectively.
>
> CSR is underway.
>
> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
> API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net
> jck:api/javax_security jck:ap
Hi,
Thanks for your message and interest in Java Security.
We are currently working on an implementation of Hybrid Key Exchange in
TLS 1.3 [1]. It will not be in JDK 25 as the release is entering
rampdown phase 1 soon.
Although we can't commit to a target release at this time, we hope to
de
On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
> respectively.
>
> CSR is underway.
>
> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
> API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net
> jck:api/javax_security jck:ap
On Tue, 20 May 2025 09:39:09 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SSLSessi
On Tue, 20 May 2025 16:28:42 GMT, Daniel Jeliński wrote:
>> If we use the same KeyStore and the same KeyManager then the certificate(s)
>> will be the same most of the time but there is no guarantee of course:
>>
>> 1. We can have different constraints in `java.security`
>> 2. Different `jdk.tl
On Mon, 19 May 2025 22:24:52 GMT, Jamil Nimeh wrote:
>> Bradford Wetmore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> get*() no longer needed, backout error (oops!)
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
> On May 20, 2025, at 05:56, Sebastian Stenzel
> wrote:
>
> Hi,
>
> thank you for your fast replies!
>
> * One benefit of using byte[] is that I can nil the PRK after I’m done (while
> secretKey.destroy() isn’t well supported, see my other post from yesterday on
> this mailing list)
Yes,
On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
>> approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally
On Tue, 20 May 2025 19:05:01 GMT, Daniel Jeliński wrote:
>> Hm.. they are being specified everywhere else in SSL code. So I guess we
>> should pass an empty string to `SecretKeySpec` constructor then?
>
> Before this PR we used a hardcoded algorithm name "TlsMasterSecret" for both
> the PSK and
On Tue, 20 May 2025 08:56:23 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SessionT
On Tue, 29 Apr 2025 18:49:52 GMT, Ferenc Rakoczi wrote:
> By using the AVX-512 vector registers the speed of the computation of the
> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
> approximately doubled.
This pull request has now been integrated.
Changeset: 972f2ebe
On Tue, 20 May 2025 17:14:06 GMT, Artur Barashev wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 324:
>>
>>> 322: b = Record.getBytes8(buf);
>>> 323: if (b.length > 0) {
>>> 324: String alg = new String(b);
>>
>> Please rem
On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
>> approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally
> By using the AVX-512 vector registers the speed of the computation of the
> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
> approximately doubled.
Ferenc Rakoczi has updated the pull request incrementally with one additional
commit since the last revision:
Added s
On Thu, 15 May 2025 13:33:42 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
>> approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally
On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-KEM algorithms (key generation, encapsulation, decapsulation) can be
>> approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally
On Tue, 20 May 2025 08:51:36 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SessionT
On Tue, 20 May 2025 11:51:49 GMT, Ferenc Rakoczi wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 250:
>>
>>> 248: static void montmul(int outputRegs[], int inputRegs1[], int
>>> inputRegs2[],
>>> 249: int scratchRegs1[], int scratchRegs2[], MacroAssembler
>>> *_m
On Tue, 20 May 2025 09:53:48 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SSLSessi
On Tue, 20 May 2025 14:49:27 GMT, Artur Barashev wrote:
> As far as I can tell local certificates are not being used by TLS layer after
> the handshake but they can be requested by application layers above such as
> HTTPS.
Right, that matches my observations.
> If having the same local certif
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk/pull/25321
>
> This PR passes tier1, tier2, and tier3
On Tue, 20 May 2025 09:05:28 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SessionT
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk/pull/25321
>
> This PR passes tier1, tier2, and tier3
On Tue, 20 May 2025 12:54:06 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
Weijun Wang has updated the pull request with a new target base due to a merge
or a rebase. The pull
On Fri, 16 May 2025 19:53:39 GMT, Weijun Wang wrote:
> This is a routine update to synchronize with the [Mozilla Public Suffix
> List](https://github.com/publicsuffix/list) for JDK 25, matching commit
> 823beb1 from 2025-05-12.
>
> The test has been updated to reflect corresponding changes.
>
On Tue, 20 May 2025 10:02:44 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SSLSessi
On Mon, 19 May 2025 20:41:13 GMT, Joe Darcy wrote:
>> They are documented in [this
>> page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)
>
> Okay -- if there is some link to the private serial-related methods even in a
> public jav
On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote:
> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
>
> A couple of `@see` tags in the [serialization
> page](https://download.java.net/java/ea
On Tue, 20 May 2025 12:54:06 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
On Tue, 20 May 2025 11:37:03 GMT, Daniel Jeliński wrote:
> This looks promising. What ticket sizes have you observed when no client
> certificates were involved?
Without peer certificates I observed only between 170 and 210 bytes.
-
PR Comment: https://git.openjdk.org/jdk/pull/253
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk/pull/25321
>
> This PR passes tier1, tier2, and tier3
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk/pull/25321
>
> In some of the cases, this is not stri
On Tue, 20 May 2025 10:51:13 GMT, Per Minborg wrote:
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk
This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
`DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
instances can be used in classes that were not covered by
https://github.com/openjdk/jdk/pull/25321
In some of the cases, this is not strictly needed
On Tue, 20 May 2025 10:51:13 GMT, Per Minborg wrote:
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk
On Fri, 16 May 2025 00:28:18 GMT, Sandhya Viswanathan
wrote:
>> Ferenc Rakoczi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Response to review comment + loading constants with broadcast op.
>
> src/hotspot/cpu/x86/stubGenerator_x86_6
On Tue, 20 May 2025 03:01:06 GMT, Artur Barashev wrote:
>> The stateless session ticket is included in the ClientHello message, either
>> in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key
>> extension (TLS1.3). With the current construction, the ticket is often the
>> la
Hi,
thank you for your fast replies!
* One benefit of using byte[] is that I can nil the PRK after I’m done (while
secretKey.destroy() isn’t well supported, see my other post from yesterday on
this mailing list)
* Another reason is that it feels clunky to specify a key algorithm for the PRK
(d
Hi Sean,
I was hoping to have the „trivial“ implementations (pure byte[] wrappers such
as SecretKeySpec etc) done before RDP1. I expect the second PR to cause more
discussions.
Cheers!
Sebastian
> On 19. May 2025, at 21:41, Sean Mullan wrote:
>
> Hi Sebastian,
>
> Thanks for your interest
Hi,
I've been trying to find out when OpenJDK will have support for hybrid key
exchange in TLS 1.3.
I've found the corresponding issue:
https://bugs.openjdk.org/browse/JDK-8314323, but not able to find any
information on the status of this work, nor what OpenJDK releases it
targets.
Is this plan
55 matches
Mail list logo
