• Registered: 2026-04-21
  • Posts: 1

Topic: Hybrid TLS 1.3 (PQC) support in wolfSSL JNI (Java)

Hello,

I’ve been reviewing the wolfSSL documentation and have tested the hybrid TLS 1.3 examples in C. On the native side, I was able to successfully compile wolfSSL with PQC_Hybrids and run the client/server examples using hybrid TLS 1.3 without any issues.

I’m new to this area, and I would like to achieve the same from Java using wolfSSL JNI. However, when checking the JSSE provider documentation, I only see references to classical algorithms, although there is also mention of the QSH (quantum-safe handshake) extension.

My questions are:
Is wolfSSL_PQC_Hybrids currently supported through wolfssl-jni-jsse?
Is the QSH extension compatible with TLS 1.3 from Java?
If not, are there any plans to expose hybrid key exchange groups in the JNI wrapper?

Any guidance would be greatly appreciated.

Share

  • Registered: 2021-07-06
  • Posts: 196

Re: Hybrid TLS 1.3 (PQC) support in wolfSSL JNI (Java)

Hello,

We don't currently support hybrid PQC or PQC in general in our Java bindings.  We are currently working on PQC support for our Java bindings.

Thanks,
Kareem

Share

  • From: India
  • Registered: 2026-07-08
  • Posts: 1

Re: Hybrid TLS 1.3 (PQC) support in wolfSSL JNI (Java)

Good news — hybrid PQC key exchange groups are supported in wolfSSL JNI/JSSE, it's just not surfaced the same way as the classical algorithms in the docs you may have been looking at.

The relevant mechanism is the wolfjsse.enabledSupportedCurves security property. This property lets you restrict/select the named groups used during the handshake, and it explicitly covers both ECC curves and PQC/hybrid groups. You set it in your java.security file (or wherever your JSSE provider config lives).

Both "compact" (e.g. MLKEM768, X25519MLKEM768) and "IETF" (e.g. ML-KEM-768, SecP256r1MLKEM768) name spellings are recognized for PQC and hybrid groups, but this only works if the native wolfSSL library was built with --enable-mlkem (in addition to --enable-jni).

Example usage would look like:

wolfjsse.enabledSupportedCurves=X25519MLKEM768, SecP256r1MLKEM768, ML-KEM-768

Keep in mind this property is the lowest-precedence source for named groups — it gets overridden by the jdk.tls.namedGroups System property, which in turn is overridden by SSLParameters.setNamedGroups() on JDK 20+, so only one of those three mechanisms will actually apply per session. If you're setting it and not seeing the hybrid group negotiated, check you don't have one of the higher-precedence sources overriding it elsewhere in your app.

So to directly answer your questions:

1. Is PQC_Hybrids supported through wolfssl-jni-jsse? Yes, as long as native wolfSSL is compiled with ML-KEM support and JNI enabled, and you configure the named groups as above.

2. Is QSH compatible with TLS 1.3 from Java? QSH is a separate, older/legacy extension and isn't the mechanism used for the modern hybrid ML-KEM key exchange in TLS 1.3 — you can disregard that for this use case.

3. Plans to expose hybrid groups? They're already exposed via the enabledSupportedCurves property described above, so no additional wrapper changes should be needed on your end.

If you're still not seeing the hybrid group show up in your ClientHello after setting this, it's worth double-checking your native wolfSSL build flags (--enable-mlkem) and posting your exact java.security config and wolfSSL JNI/JSSE version — that'll help narrow down whether it's a build-time or config-time issue.

Pankaj007's Website

Share