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

[Peter Gutmann <[e-mail]>]

D. J. Bernstein <[e-mail]> writes:

>https://arxiv.org/abs/2107.04940 studied hundreds of CVEs in crypto
>libraries. There was roughly 1 new CVE per 1000 lines of new code. About 1
>out of 8 "cryptographic" CVEs was severe.

Thanks for that ref, I'd missed that one when it was first published.  Another
interesting data point from the study is that nearly 3/4 of all vulns in
crypto libraries aren't crypto issues, and that:

  we find evidence of a strong correlation between the complexity of these
  libraries and their (in)security, empirically demonstrating the potential
  risks of bloated cryptographic codebases

Very apropos considering the neverending stream of codebase bloat enhancement
drafts posted here... I've already mentioned this in the past but one of the
major skills needed with security/crypto standards is knowing which parts of
them, and in some cases which entire standards, you can and in fact need to
for security purposes, ignore.  I don't mean the "check that the point is on
the curve" stuff but the "here's a cool idea I had in the shower this morning"
stuff.

(This is why security developers are at least one thing that AI will never put
out of a job, you need actual skill to sort the mess out, not just an ability
to code from a spec).

If WGs like TLS and LAMPS adopted the rule "every time you add something you
need to take something else out" we'd have vastly less complexity/bloat-driven
vulnerabilities.  And, with the elimination of the red-queen problem, stable
standards where you can spend the time to get the implementation right knowing
it won't have some new piece of complexity bolted onto it next week, and the
week after, and the week after that.

Peter.