On Thu, Feb 26, 2026 at 04:37:31PM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote:

TLS client of OpenSSL version 3.5 or later specifies hybrid key exchange of ECC and Post-Quantum (such as X25519MLKEM768) and an ECC key exchange (such as X25519) in TLS ClientHello.

Indeed, and I expect to be able to find some cycles to help out on the Haskell side too.

I have implemented both the hybrid algorithms and the OpenSSL specifying-method in the Haskell "tls" library. Interop with OpenSSL is quite good.

I'm very curious what you mean when you say "the OpenSSL specifying-method"..

I would like to discuss how to specify algorithms in ClientHello before releasing. If you are interested, I would like to invite you to this issue:

https://github.com/haskell-tls/hs-tls/issues/516

I thank Olivier Chéron for implementing excellent "mlkem" library.

You have my Google Chat contact, please reach out. OpenSSL 4.0 (slated for release in ~Apri) clients will also advertise support for SecP2561MLKEM768 and sm2curveMLKEM768, though only the first of the triple: X25519MLKEM768, SecP256r1MLKEM768, curveSM2768 that is was enabled at compile-time, and was not disabled at runtime via, e.g., "DEFAULT:-?X25519MLKEM768", is included among the client's predicted keyshares. I should perhaps also note that some servers are behind middleboxes (buggy or at least overzealous firewalls, ...) that choke on the size of the resulting TLS Client Hello. The Postfix SMTP TLS client therefore chooses a non-default configuration that still advertises support for X25519MLKEM, but suppresses the keyshare prediction. This trades off edge-case reliability against latency, as now servers that do prefer hybrid PQ will send a Hello Retry Request (HRR) adding a round-trip. -- Viktor. 🇺🇦 Слава Україні!