[CFRG] Re: RG Last Call on draft-irtf-cfrg-hybrid-kems-12 and draft-irtf-cfrg-concrete-hybrid-kems-04

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

Muhammad Usama Sardar writes:
> If there was no such CVE in the last decade after that, doesn't
> that indicate that it was just a random one-time implementation bug?

I didn't notice any followups addressing this question. Let me emphasize
the engineering perspective.

https://blog.cr.yp.to/20191024-eddsa.html says that "the Minerva team is
claiming to break ECDSA in 4 or possibly 5 out of 13 crypto libraries
supporting ECDSA, and EdDSA in 0 out of 9 crypto libraries supporting
EdDSA. ... I'm not saying that it's impossible to implement EdDSA
insecurely. Of course it's _possible_ to implement EdDSA insecurely.
Maybe there are people using insecure EdDSA implementations today. But
the Minerva data points support the theory that **EdDSA implementations
are less likely to be broken than ECDSA implementations**. This isn't an
accident: it's how EdDSA was designed in the first place."

The question of whether software will end up vulnerable involves some
effects that we can control in the cryptosystem design and some random
effects. That's why ECDSA didn't _always_ end up vulnerable to Minerva.
About 1/3 of the studied libraries were vulnerable.

If we're designing a software-engineering process, then some of the
random effects suddenly become controllable (e.g., whether the software
is tested with valgrind), but there are still random effects (e.g.,
whether a programmer happens to make a particular mistake).

Extrapolating from a single bug is of course statistically invalid. This
is why risk assessment creates models of mechanisms by which bugs happen
and then, recognizing the risk of mistakes in the models, tests those
models against many data points.

For example, it's common to model each bug as having a constant chance
of being discovered each year (by, e.g., reviews). The data set in

    https://www.usenix.org/conference/usenixsecurity22/presentation/alexopoulos

shows an excellent fit to this across many years: vulnerabilities in
well-known open-source projects have about a 20% chance each year of
being discovered. For example, code that's 10 years old is roughly six
times less risky than the same volume of code that's only 2 years old,
simply because there's more time for its bugs to have been eliminated.

Is bug discovery slower for closed-source projects? Or for projects
that aren't as well known? How much is AI increasing the discovery rate
of bugs? How much is it hurting by increasing the code volume and bug
volume to begin with? Answering such questions by extrapolation from
isolated data points is again statistically invalid.

Understanding the evidence that's available regarding failure mechanisms
and failure rates is what produces the advice that you find in books on
software engineering. For example: Use more tests. Use tests more likely
to catch bugs. Prefer smaller code. Prefer easier-to-test code. But note
that sometimes these goals are in conflict---e.g., should more mature
code be replaced by newer, smaller code? see

    https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

for one side of the neverending debate---and there's always the question
of how to allocate human time.

Starting from these general concepts, you can ask how ECC in particular
can be designed to reduce risks: for example, how different choices in
ECC specs allow smaller code. Smaller code is often in tension with
faster code (see, e.g., libraries having Intel code and ARM code along
with relatively simple portable code)---which is important: complaints
about speed, whether justified or not, continually interfere with
deployment of better security---but it turns out that some changes to
ECC designs, such as using the Montgomery ladder and using a prime very
close to a power of 2, make code simultaneously smaller _and_ faster.
See

    https://blog.cr.yp.to/20140323-ecdsa.html

for an introduction to the ECC design space in the case of signatures,
and see

    https://cr.yp.to/papers.html#safecurves

for much more material. Quite a few of the choices matter for the
ECC+KEM context rather than being signature-specific.

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