Hybrid PQC: x25519-mlkem fails in openssl 3.5.5 with default provider

[murugesh pitchaiah]

Hi All,

I have downloaded the openssl 3.5.5 code base and built the library. While trying to generate the hybrid ml-kem keypair see below error:

(snip)

$ openssl genpkey -algorithm X25519MLKEM768 -out x25519_mlkem_768_key.pem

Error writing key(s)

80CB0C248B760000:error:1D800065:ENCODER routines:OSSL_ENCODER_to_bio:reason(101):crypto/encode_decode/encoder_lib.c:78:No encoders were found. For standard encoders you need at least one of the default or base providers available. Did you forget to load them?

80CB0C248B760000:error:04800073:PEM routines:do_pk8pkey:error converting private key:crypto/pem/pem_pk8.c:132:

$ openssl list -providers

Providers:

  default

    name: OpenSSL Default Provider

    version: 3.5.5

    status: active

$ 

$ openssl list -kem-algorithms | grep -i mlkem

  { 2.16.840.1.101.3.4.4.1, id-alg-ml-kem-512, ML-KEM-512, MLKEM512 } @ default

  { 2.16.840.1.101.3.4.4.2, id-alg-ml-kem-768, ML-KEM-768, MLKEM768 } @ default

  { 2.16.840.1.101.3.4.4.3, id-alg-ml-kem-1024, ML-KEM-1024, MLKEM1024 } @ default

  X25519MLKEM768 @ default

  X448MLKEM1024 @ default

  SecP256r1MLKEM768 @ default

  SecP384r1MLKEM1024 @ default

$ 

(snip)

I assume the support is added by default and no provider load is needed. Can anyone please share what am i missing ? Thanks in advance.

Regards,

Murugesh

[Tomas Mraz]

Hi,

Yes, the X25519MLKEM768 does NOT have any defined private key format
and for that reason it is usable only for ephemeral keys.

Regards,

Tomas Mraz, CTO, OpenSSL Foundation

> --
> You received this message because you are subscribed to the Google
> Groups "openssl-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openssl-user...@openssl.org.
> To view this discussion visit
> https://groups.google.com/a/openssl.org/d/msgid/openssl-users/CAOu9RAdFHfB4_RtCsD79tNTCuE3PiUtOn31Ora82dE_LYgPzcw%40mail.gmail.com
> .

--
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy… everywhere.
https://openssl.foundation/donate/ways-to-give

[murugesh pitchaiah]

Hi Tomas,

Thanks for the reply.  Please share  what's the hybrid algorithm can be used for a complete TLS client/server.  ( To generate x509 key and certificate)

If no such support available,  only way is to use ml-dsa ? (non hybrid)

Thanks, 

Murugesh 

[Viktor Dukhovni]

On Fri, Mar 27, 2026 at 10:25:38PM +0530, murugesh pitchaiah wrote:

> Thanks for the reply. Please share what's the hybrid algorithm can be
> used for a complete TLS client/server. ( To generate x509 key and
> certificate)

The OpenSSL default provider's X25519MLKEM768 algorithm is a hybrid TLS
KEM, (KEM == Key Encapsulation Mechanism), which is a form of **key
exchange**, analogous to (FF)DHE or ECDHE.

In TLS, It is a PQC alternative to use of, e.g., just X25519. In either
case the keys are *ephemeral* single-use keys, generated on the fly, and
never loaded from, or stored to, the filesystem. They are not
authentication keys, and DO NOT appear in certificates.

If what you want is a PQC server certificate (not just key exchange),
the only realistic choice at presennt is ML-DSA, and waht I hear from
the engineers at places like CloudFlare, Google, ... is that ML-DSA-44
has an adequate security margin, and there's no present need to consider
stronger its variants ML-DSA-65 or ML-DSA-87.

Also, authentication keys are not a harvest-now-decrypt-later risk, so
in many cases there's no immediate urgency to deploy PQC authentication
keys in TLS. You can keep using certificates based on RSA or ECDSA with
no (known) immediate risk.

> If no such support available, only way is to use ml-dsa ? (non
> hybrid)

The story with hybrid certificates is much more nuanced than that with
hybrid key exchange, the data formats were just finalised at the most
recent IETF or so, but there are way too many choices, most of which are
impractical, and no mainstream CAs issuing certificates for any of them.

You can use ML-DSA-44, if your use-case is particularly compelling, or
you just want to test. There's no real incentive to use a hybrid in the
TLS use-case and we may never need hybrids for authentication, they're
best avoided. In the believed unlikely case that at some future time
ML-DSA-44 is found to be weak, you'll choose a different certificate
algorithm.

--
Viktor. 🇺🇦 Слава Україні!

[murugesh pitchaiah]

Hi Victor,

Thanks a lot for your reply. Its with great details indeed. 

One more question.  Incase my requirement is old RSA certs plus only ML-KEM for key exchange alone, shall I use the hybrid x25519mlkem768 just like below ctx set group code, with existing RSA certificate in both client and server?

SSL_CTX_set1_groups_list(ctx, "X25519MLKEM768");

If yes, is it natively supported with default provider in openssl 3.5.5? Or need oqs provider?

Thanks, 

Murugesh 

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/acbFPfR4aJyGpOKK%40chardros.imrryr.org.

[murugesh pitchaiah]

Adding to below mail:

I see from 3.5.0 changelog:

(snip)

ML-KEM as specified in FIPS 203.

Based on the original implementation in BoringSSL, ported from C++ to C, refactored, and integrated into the OpenSSL default and FIPS providers. Including also the X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 TLS hybrid key post-quantum/classical key agreement schemes.

(snip)

Does that mean even without explicit group set, it's included already in TLS 1.3 handshake ? For RSA certificate too ?

Thanks, 

Murugesh 

[Viktor Dukhovni]

On Sat, Mar 28, 2026 at 01:06:59PM +0530, murugesh pitchaiah wrote:

> One more question. Incase my requirement is old RSA certs plus only ML-KEM
> for key exchange alone, shall I use the hybrid x25519mlkem768 just like
> below ctx set group code, with existing RSA certificate in both client and
> server?
>
> SSL_CTX_set1_groups_list(ctx, "X25519MLKEM768");

No, because the default group list already includes X25519MLKEM,
but also includes other groups that improve interoperability.
That setting is unnecessary.

> If yes, is it natively supported with default provider in openssl 3.5.5? Or
> need oqs provider?

You do not need the OQS provider, and it is best avoided in production
configuratons.

--
Viktor. 🇺🇦 Слава Україні!

[Viktor Dukhovni]

On Sat, Mar 28, 2026 at 02:37:59PM +0530, murugesh pitchaiah wrote:

> Based on the original implementation in BoringSSL, ported from C++ to C,
> refactored, and integrated into the OpenSSL default and FIPS providers.
> Including also the X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024
> TLS hybrid key post-quantum/classical key agreement schemes.
>
> (snip)
>
> Does that mean even without explicit group set, it's included already in
> TLS 1.3 handshake ? For RSA certificate too ?

Yes, and the certificate is irrelevant. In TLS 1.3 key exchange groups
are negotiated independently of the certificates.

--
Viktor. 🇺🇦 Слава Україні!

[murugesh pitchaiah]

Thanks Victor for quick response. 

Regards, 

Murugesh 

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/ace170Dd2YSU6oN1%40chardros.imrryr.org.