Marc Penninga writes:
> Hybrid key exchanges also require both *keys* to be independent, and
> the combiner function to be theoretically sound, and the combiner
> function to be implemented correctly.

A few lines of combiner code for key exchange or for signatures can
certainly have bugs, just like other lines of code. Maybe someone will
find an example someday where a combiner bug slipped past testing _and_
made ECC+PQ easier than PQ to break in TLS.

But it makes absolutely no sense to worry more about this than about the
risk of devastating bugs in a much larger volume of code for ML-KEM and
ML-DSA. See https://cr.yp.to/papers.html#pqcomplexity for size metrics
for ML-KEM reference code (never mind the extra complications of code
aiming for higher speed). ML-DSA code is even larger than ML-KEM code.

https://blog.cr.yp.to/20240102-hybrid.html#morecomplicated already
explained this. See in particular the comments on the possibility of a
"devastating bug in the lines of code for the hybrid hash" vs. "the risk
of an exploit of a post-quantum implementation". Those comments cited
KyberSlash as a then-recent example of a demonstrated PQ vulnerability.

Of course, PQ security failures aren't just software failures. SIKE, for
example, was applied to tens of millions of TLS user sessions as part of
CECPQ2b. The only reason that the SIKE break didn't immediately violate
the confidentiality of all of this user data is that CECPQ2b also had an
ECC layer. And then there's https://cr.yp.to/papers.html#qrcsp surveying
breaks of 48% of the 69 post-quantum proposals in the NIST competition,
often with very fast attacks.

> All of which I have seen go wrong in real-world code.

How about giving some URLs and summaries of the supposed impact, so that
readers can compare what you're talking about to the neverending parade
of verifiable public examples of PQ security disasters?

John Mattsson writes:
> Poorly designed hybrids can actually be easier to attack than any of
> their constituent components individually. One example is [1], which
> inherits the malleability weakness of ECDSA
  [ etc. ]

When you use the word "weakness", are you claiming something that
reduces TLS security? Or even _potentially_ reduces TLS security? (Did I
miss some effort to ban ECDSA from TLS on this basis?)

How do you reconcile this claim with https://eprint.iacr.org/2020/1029
having theorems saying that all TLS needs from a signature system is the
standard "EUF-CMA" property, i.e., the inability of attackers to forge
signatures on new messages?

Simply concatenating a fixed-length ECC signature with a PQ signature,
and verifying both, is a safe way to handle ECC+PQ for any protocol
whose security relies purely on EUF-CMA. The attacker can't forge a
concatenated signature on a new message without forging the ECC
signature on that message _and_ the PQ signature on that message.

As I've commented elsewhere, it's possible to spend endless time
discussing other options for a few lines of code for the combiner. For
example, https://pqcrypto.eu.org/deliverables/d2.5.pdf#subsection.3.3
recommends an alternative of using the second signature system to sign
the first signed message. Mothma has very slight extra complications,
which I believe are justified by the protection against various weird
things that protocols might do. But please don't mislead people into
thinking that any of these extra protections matter for TLS.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

Rationale: I'm fine with redistribution of copies of this document. The
issue is with modification, such as (1) IESG's May 2025 posting of an
IESG-mangled version of an appeal that I had filed and (2) IETF
management selling IETF mailing-list text to AI companies.