John Mattsson writes:
> Note that once a CRQC emerges, which some people say may happen very
> soon, the X25519 component no longer provides any security

It will happen soon (I'm on the record already in 2023 giving a median
estimate of 2029 for the first secret quantum attacks and 2032 for the
first public quantum attacks), but the "no longer provides any security"
claim overstates the number of broken keys by ten orders of magnitude.

Concretely, the following paper explains how a reasonable model of the
first quantum computer will be able to break about 2^15 ECC keys/year:

    https://web.archive.org/web/20260331050640/https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf

IBM is spending $10 billion over five years to try to build the first
public quantum computer:

    https://www.reuters.com/technology/ibm-plans-10-billion-investment-large-scale-quantum-computer-by-2029-2026-05-28/

The article says 2029, but my understanding is that this is when IBM
expects sustained error-corrected computations on _a few_ qubits. I'm
sticking to 2032 as my median estimate for a public quantum attack. (I
expect large-scale attackers such as NSA to be a few years ahead.)

Even if ~90% of the $10 billion is NRE cost, the computer will cost ~$1
billion for breaking ~2^15 ECC keys/year. That's terrible for _those
keys_, but the _cryptosystem_ continues to provide security for _other_
keys. There are more than 2^50 X25519 keys generated each year.

See https://cr.yp.to/papers/mldsa-20260601.pdf#ecc for further analysis
and references. My paper focuses on signatures rather than encryption,
and I'm assuming only 2^30 signature keys active at each moment, but
2^15 broken keys still leaves 99.99% of the keys safe.

Am I saying that 99.99% safe is good enough? No. Also, quantum attacks
will become more cost-effective as the years pass. Also, some attackers
have multi-billion-dollar-a-year attack budgets.

But what you're recommending will produce a _much worse_ situation,
because severe vulnerabilities in signature software will lead to breaks
of far more than 2^15 signature keys per year:

    https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys

Furthermore, those vulnerabilities will be exploitable by small-scale
attackers, not just attackers with a quantum computer. The exploit
scripts in my paper break each key in <1 second on 1 laptop core.

ECC+ML-DSA is a much safer option than solo ML-DSA (and has negligible
cost beyond solo ML-DSA). Maybe the attacker can break the ECC key _and_
the ML-DSA key, but this will be much less frequent than breaking _just_
the ML-DSA key. Maybe a program-partitioning problem such as a buffer
overflow lets the attacker get away with breaking just one of the two
systems, but this will also be less frequent than breaking _just_ the
ML-DSA key.

Sure, this benefit disappears in the extreme scenarios that (1) all ECC
keys are broken or that (2) no ML-DSA keys are broken. But all available
evidence says that we're not in those extreme scenarios.

---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 "has a license" to do anything it wants.