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

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 =3D=3D 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.

--=20
    Viktor.  =F0=9F=87=BA=F0=9F=87=A6 =D0=A1=D0=BB=D0=B0=D0=B2=D0=B0 =D0=A3=
=D0=BA=D1=80=D0=B0=D1=97=D0=BD=D1=96!

--=20
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 e=
mail to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msg=
id/openssl-users/acbFPfR4aJyGpOKK%40chardros.imrryr.org.