Re: Hybrid PQC: x25519-mlkem fails in openssl 3.5.5 with default provider
murugesh pitchaiah <[email protected]> Sat, 28 Mar 2026 13:06:59 +0530
| Newsgroups | gmane.comp.encryption.openssl.user |
|---|---|
| Message-ID | <CAOu9RAf7wSMQcPqXdi079PqWOP=WFkDSec5iGfHq_4R1ZP_ueQ@mail.gmail.com> |
--0000000000007ed1ab064e10af99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Fri, 27 Mar, 2026, 11:28=E2=80=AFpm Viktor Dukhovni, <openssl-users@dukh= ovni.org> wrote: > 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. > > -- > 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! > > -- > 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-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org > To view this discussion visit > https://groups.google.com/a/openssl.org/d/msgid/openssl-users/acbFPfR4aJy= GpOKK%40chardros.imrryr.org > . > --=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/CAOu9RAf7wSMQcPqXdi079PqWOP%3DWFkDSec5iGfHq_4R1ZP_ueQ%40ma= il.gmail.com. --0000000000007ed1ab064e10af99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Hi Victor,</div><div dir=3D"auto"><br></div><div dir= =3D"auto">Thanks a=C2=A0lot for your reply. Its with great details indeed.= =C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">One=C2=A0more que= stion.=C2=A0 Incase my requirement is old RSA certs plus only ML-KEM for ke= y exchange alone, shall I use the hybrid x25519mlkem768 just like below ctx= set group code, with existing RSA certificate in both client and server?</= div><div dir=3D"auto"><br></div><div dir=3D"auto">SSL_CTX_set1_groups_list(= ctx, "X25519MLKEM768");</div><div dir=3D"auto"><br></div><div dir= =3D"auto">If yes, is it natively supported with default provider in openssl= 3.5.5? Or need oqs provider?</div><div dir=3D"auto"><br></div><div dir=3D"= auto">Thanks,=C2=A0</div><div dir=3D"auto">Murugesh=C2=A0<br><br><div class= =3D"gmail_quote gmail_quote_container" dir=3D"auto"><div dir=3D"ltr" class= =3D"gmail_attr">On Fri, 27 Mar, 2026, 11:28=E2=80=AFpm Viktor Dukhovni, <= ;<a href=3D"mailto:[email protected]">[email protected]</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Mar 27, 2026 = at 10:25:38PM +0530, murugesh pitchaiah wrote:<br> <br> > Thanks for the reply.=C2=A0 Please share=C2=A0 what's the hybrid a= lgorithm can be<br> > used for a complete TLS client/server.=C2=A0 ( To generate x509 key an= d<br> > certificate)<br> <br> The OpenSSL default provider's X25519MLKEM768 algorithm is a hybrid TLS= <br> KEM, (KEM =3D=3D Key Encapsulation Mechanism), which is a form of **key<br> exchange**, analogous to (FF)DHE or ECDHE.<br> <br> In TLS, It is a PQC alternative to use of, e.g., just X25519.=C2=A0 In eith= er<br> case the keys are *ephemeral* single-use keys, generated on the fly, and<br= > never loaded from, or stored to, the filesystem.=C2=A0 They are not<br> authentication keys, and DO NOT appear in certificates.<br> <br> If what you want is a PQC server certificate (not just key exchange),<br> the only realistic choice at presennt is ML-DSA, and waht I hear from<br> the engineers at places like CloudFlare, Google, ... is that ML-DSA-44<br> has an adequate security margin, and there's no present need to conside= r<br> stronger its variants ML-DSA-65 or ML-DSA-87.<br> <br> Also, authentication keys are not a harvest-now-decrypt-later risk, so<br> in many cases there's no immediate urgency to deploy PQC authentication= <br> keys in TLS.=C2=A0 You can keep using certificates based on RSA or ECDSA wi= th<br> no (known) immediate risk.<br> <br> > If no such support available,=C2=A0 only way is to use ml-dsa ? (non<b= r> > hybrid)<br> <br> The story with hybrid certificates is much more nuanced than that with<br> hybrid key exchange, the data formats were just finalised at the most<br> recent IETF or so, but there are way too many choices, most of which are<br= > impractical, and no mainstream CAs issuing certificates for any of them.<br= > <br> You can use ML-DSA-44, if your use-case is particularly compelling, or<br> you just want to test.=C2=A0 There's no real incentive to use a hybrid = in the<br> TLS use-case and we may never need hybrids for authentication, they're<= br> best avoided.=C2=A0 In the believed unlikely case that at some future time<= br> ML-DSA-44 is found to be weak, you'll choose a different certificate<br= > algorithm.<br> <br> -- <br> =C2=A0 =C2=A0 Viktor.=C2=A0 =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!<br> <br> -- <br> You received this message because you are subscribed to the Google Groups &= quot;openssl-users" group.<br> To unsubscribe from this group and stop receiving emails from it, send an e= mail to <a href=3D"mailto:openssl-users%[email protected]" target= =3D"_blank" rel=3D"noreferrer">openssl-users+unsubscribe-MCmKBN63+BlAfugRpC6u6w@public.gmane.org</a>.<b= r> To view this discussion visit <a href=3D"https://groups.google.com/a/openss= l.org/d/msgid/openssl-users/acbFPfR4aJyGpOKK%40chardros.imrryr.org" rel=3D"= noreferrer noreferrer" target=3D"_blank">https://groups.google.com/a/openss= l.org/d/msgid/openssl-users/acbFPfR4aJyGpOKK%40chardros.imrryr.org</a>.<br> </blockquote></div></div></div> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups &= quot;openssl-users" group.<br /> To unsubscribe from this group and stop receiving emails from it, send an e= mail to <a href=3D"mailto:openssl-users+unsubscribe-MCmKBN63+BlAfugRpC6u6w@public.gmane.org">openssl-us= [email protected]</a>.<br /> To view this discussion visit <a href=3D"https://groups.google.com/a/openss= l.org/d/msgid/openssl-users/CAOu9RAf7wSMQcPqXdi079PqWOP%3DWFkDSec5iGfHq_4R1= ZP_ueQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://gro= ups.google.com/a/openssl.org/d/msgid/openssl-users/CAOu9RAf7wSMQcPqXdi079Pq= WOP%3DWFkDSec5iGfHq_4R1ZP_ueQ%40mail.gmail.com</a>.<br /> --0000000000007ed1ab064e10af99--