[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:
> Again, without going into detail, please note that you are pointing me to a
> seven-years old reference. I am interested in knowing the state-of-the-art.

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

The newer evidence is further confirmation of the patterns covered in
the 2019 posting, and matches the predictions we made years before that.

> The unstated assumption here seems to be that the number of broken
> implementations is representative of the quality of algorithm.

No. There's a continual process of building models to predict failures,
testing those models against the available evidence, building better
models, etc. I mentioned investigations of traps for ECC implementors
(those are examples of building models) and subsequent tests against
observations of failures.

> Say I like algorithm A and don't like algorithm B. What if I put out
> several naive/intentionally broken implementations of B to show that
> it is bad and we should use the algorithm A?

Sorry, are you trying to suggest that the Minerva vulnerabilities in

    * the ECDSA implementation in the FIPS-certified CC-certified
      "Athena IDProtect card with CPLC data 010b.0352.0005",
    * the ECDSA implementations in seven other certified devices broken
      in the same paper,
    * the ECDSA implementation in libgcrypt,
    * the ECDSA implementation in MatrixSSL,
    * the ECDSA implementation in SunEC/OpenJDK/Oracle JDK,
    * the ECDSA implementation in Crypto++, and, as a newer example,
    * the ECDSA implementation in Firefox,

come from an attacker supplying all of those implementations so as to
corrupt subsequent risk evaluations or retroactively justify earlier
faked risk evaluations?

I don't mean to dismiss the possibility of cryptographic sabotage---on
the contrary,

    https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf

shows a large sabotage budget, and I have some papers studying sabotage
possibilities. But somehow the primary problem with the scenario you're
talking about looks like the attacker being able to insert code into a
wide range of deployments. Anyway, the possibility of sabotage doesn't
stop people from studying accidental failures and developing mitigations
based on the evidence available.

> > The question of whether software will end up vulnerable involves some
> > effects that we can control in the cryptosystem design and some random
> > effects.
> Can you share some examples of these random effects?

I already did: e.g., mentioning "whether the software is tested with
valgrind" as an example of something that's controllable for people
designing software-engineering processes but random for people writing
cryptographic specs, and mentioning "whether a programmer happens to
make a particular mistake" as something that's random both ways.

> > Is bug discovery slower for closed-source projects?
> In general, yes, simply because most likely not enough people have
> looked at it, tested it, and formally verified it.

Those statements are examples of formulating a model of some effects
that influence risks. But what if closed-source projects can afford more
investment in code quality? It's not obvious how big these effects are.

> > Prefer smaller code.
> This seems too vague: smaller number of lines of code? smaller memory
> consumption? smaller runtime? Could you please explain and justify this?

As I wrote before: "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."

There's a continual process of programmers producing more code, in some
cases screwing up. Obviously more code is correlated with more screwups
(even if there are exceptions to that, such as more test code or defense
in depth). There are endless recommendations of ways to get the job done
with fewer screwups, most commonly with less code.

Time and memory can matter here when they limit tests, but that's a
secondary effect.

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