Re: Hybrid PQC: x25519-mlkem fails in openssl 3.5.5 with default provider
murugesh pitchaiah <[email protected]> Sat, 28 Mar 2026 14:37:59 +0530
| Newsgroups | gmane.comp.encryption.openssl.user |
|---|---|
| Message-ID | <CAOu9RAeC7p1-umV5xYuF13xMqawbwFkwjzULHkzVXKrk5PrcAQ@mail.gmail.com> |
--000000000000e907a6064e11f4ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Sat, 28 Mar, 2026, 1:06=E2=80=AFpm murugesh pitchaiah, < [email protected]> wrote: > 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 clie= nt > 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, < > [email protected]> 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 b= e >> > 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 Group= s >> "openssl-users" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> 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/acbFPfR4aJ= yGpOKK%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/CAOu9RAeC7p1-umV5xYuF13xMqawbwFkwjzULHkzVXKrk5PrcAQ%40mail= .gmail.com. --000000000000e907a6064e11f4ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Adding to below mail:</div><div dir=3D"auto"><br></d= iv><div dir=3D"auto">I see from 3.5.0 changelog:</div><div dir=3D"auto"><br= ></div><div dir=3D"auto">(snip)</div><div dir=3D"auto"><br></div><div dir= =3D"auto"><p dir=3D"auto" style=3D"margin-top:16px;margin-bottom:16px;color= :rgb(240,246,252);font-family:"mona sans vf",-apple-system,blinkm= acsystemfont,"segoe ui","noto sans",helvetica,arial,san= s-serif,"apple color emoji","segoe ui emoji";font-size:= 16px;background-color:rgb(13,17,23)">ML-KEM as specified in FIPS 203.</p><p= dir=3D"auto" style=3D"margin-top:16px;margin-bottom:16px;color:rgb(240,246= ,252);font-family:"mona sans vf",-apple-system,blinkmacsystemfont= ,"segoe ui","noto sans",helvetica,arial,sans-serif,&quo= t;apple color emoji","segoe ui emoji";font-size:16px;backgro= und-color:rgb(13,17,23)">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, S= ecP384r1MLKEM1024 TLS hybrid key post-quantum/classical key agreement schem= es.</p></div><div dir=3D"auto"><br></div><div dir=3D"auto">(snip)</div><div= dir=3D"auto"><br></div><div dir=3D"auto">Does that mean even without expli= cit group set, it's included already in TLS 1.3 handshake ? For RSA cer= tificate too ?</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div= ><div dir=3D"auto">Thanks,=C2=A0</div><div dir=3D"auto">Murugesh=C2=A0</div= ><div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir= =3D"ltr" class=3D"gmail_attr">On Sat, 28 Mar, 2026, 1:06=E2=80=AFpm muruges= h pitchaiah, <<a href=3D"mailto:[email protected]" target=3D"= _blank" rel=3D"noreferrer">[email protected]</a>> wrote:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hi Victor,</div>= <div dir=3D"auto"><br></div><div dir=3D"auto">Thanks a=C2=A0lot for your re= ply. Its with great details indeed.=C2=A0</div><div dir=3D"auto"><br></div>= <div dir=3D"auto">One=C2=A0more question.=C2=A0 Incase my requirement is ol= d 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 certi= ficate 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 support= ed 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"aut= o">Murugesh=C2=A0<br><br><div class=3D"gmail_quote" 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]" rel=3D"norefer= rer noreferrer" target=3D"_blank">[email protected]</a>> wrote:= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-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]" rel=3D"n= oreferrer noreferrer noreferrer" target=3D"_blank">openssl-users+unsubscrib= [email protected]</a>.<br> 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 noreferrer noreferrer" target=3D"_blank">https://grou= ps.google.com/a/openssl.org/d/msgid/openssl-users/acbFPfR4aJyGpOKK%40chardr= os.imrryr.org</a>.<br> </blockquote></div></div></div> </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/CAOu9RAeC7p1-umV5xYuF13xMqawbwFkwjzULHkzVXKrk5P= rcAQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://group= s.google.com/a/openssl.org/d/msgid/openssl-users/CAOu9RAeC7p1-umV5xYuF13xMq= awbwFkwjzULHkzVXKrk5PrcAQ%40mail.gmail.com</a>.<br /> --000000000000e907a6064e11f4ee--