Note that the hybrid PQ/T algorithms in TLS 1.3 use a trivial concetanating
combiner.

The implications of this are discussed in
https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#name-security-considerations
:

The shared secrets computed in the hybrid key exchange should be computed
in a way that achieves the "hybrid" property: the resulting secret is
secure as long as at least one of the component key exchange algorithms is
unbroken. See [GIACON
<https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#GIACON>
] and [BINDEL
<https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#BINDEL>
] for an investigation of these issues. Under the assumption that shared
secrets are fixed length once the combination is fixed, the construction
from Section 3.3
<https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#construction-shared-secret>
corresponds to the dual-PRF combiner of [BINDEL
<https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#BINDEL>
] which is shown to preserve security under the assumption that the hash
function is a dual-PRF.

-Ekr


On Mon, Jun 29, 2026 at 2:32 PM David Stainton <[email protected]>
wrote:

> The argument "hybrid will always be less secure" is incorrect, and the
> reason is the defining property of any secure KEM combiner.
> This secure KEM combiner for example: https://eprint.iacr.org/2018/024
>
> On Mon, Jun 29, 2026 at 5:53 PM Blumenthal, Uri - 0553 - MITLL
> <[email protected]> wrote:
> >
> > >> * For the time being, hybrid cryptography appears clearly less secure
> than solo post-quantum cryptography
> >
> > >>  I do not support the publication of this document.
> >
> >  >
> >
> > > Less secure but should be used ?
> >
> >
> > Hybrid will always be less secure, if (a) you agree that CRQC is coming,
> and (b) your data will remain sensitive through that time.
> >
> >
> > Therefore, IMHO it should not be used — but unlike some others on this
> list, I want those who have reasons to use Hybrid, to be able to do so,
> without having to convince me that they truly really want/need it.
> >
> > _______________________________________________
> > TLS mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to