[CFRG] Re: Silithium - A Compact, Efficient and Non-separable Hybrid Signature

["D. J. Bernstein" <[e-mail]>]

Neil Madden writes:
> A competent risk assessment would surely consider all plausible
> possible outcomes and have contingencies for all, but in the
> cryptographic community we seem to have already decided, ahead of the
> engineering, that CRQCs are inevitable and that pure-PQ is the only
> conceivable future.

I understand that you're challenging these notions, but you're also
bolstering them by claiming that the notions are what "the cryptographic
community" has decided. Do you have a basis for this claim?

I think that what matters for CFRG investigating how to best do ECC+PQ
is that there's extensive evidence of justified interest in

    * adding a PQ layer asap to try to stop quantum attacks while also
    * keeping the ECC layer to reduce damage from PQ security failures.

For example, if you look at the recent comments in

    https://web.archive.org/web/20260710230832/https://www.linkedin.com/posts/billatnapier_the-debate-around-hybrid-key-exchange-ecdh-activity-7480546081622196225-aldO

you see ML-KEM team member Roberto Avanzi (who surely counts as part of
the cryptographic community) writing the following: "I would not trust
using it exclusively: what if it gets broken mathematically and in the
classical computational model (I.e. non-quantum)? Hybrid is better, and
the additional time used by ECC is not significant."

A recent TLS WG "last call" on solo ML-KEM---the third "last call" for
that document; one participant wrote that last calls will continue until
morale improves---received objections from more than 80 people. The main
theme of the objections was that solo PQ incurs security risks compared
to ECC+PQ. This is more evidence of the interest in ECC+PQ.

If there's a 2032 demo of a billion-dollar quantum computer capable of
breaking thousands of ECC keys per year, will the interest in ECC+PQ
suddenly disappear? No. We'll have seen a bunch more PQ CVEs by then,
including some severe CVEs, and it'll sound incredibly incompetent to
say "Let's make each of these CVEs much cheaper to exploit".

More to the point, the possibility of ECC+PQ eventually being as easy to
exploit as solo PQ doesn't remove the value of CFRG looking into ECC+PQ
now. Of course, CFRG should look at safety in protocols far beyond TLS.

I should note that the same TLS WG "last call" received support
statements for solo ML-KEM from a similar volume of people. There were,
for example,

    * 6 positive votes from NSA employees (Mike Jenkins, Nicholas
      Gajcowski, William Layton, Morgan Stern, Peter Yee from his Akayla
      address, Mark Motley from his home address);

    * 2 positive votes from other DoD people (Ann Krieger and DoD lifer
      Michael StJohns),

    * 4 positive votes from Cisco employees (Eliot Lear, David McGrew,
      Richard Barnes, and Scott Fluhrer, who had written "that's what
      they're willing to buy. Hence, Cisco will implement it"),

etc. But this doesn't make support for solo PQ a community decision.
Furthermore, quite a few of the support statements were saying that
ECC+PQ is recommended and solo PQ isn't, while far fewer were making the
extreme claim that ECC is useless.

---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.

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead 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. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.