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

[Muhammad Usama Sardar <[e-mail]>]

Hi D. J. Bernstein,

On 12.07.26 20:22, D. J. Bernstein wrote:
> 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?
>   Let me emphasize
> the engineering perspective.
>
> https://blog.cr.yp.to/20191024-eddsa.html
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.
>   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.

The unstated assumption here seems to be that the number of broken 
implementations is representative of the quality of algorithm. Is it a 
good criteria? 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?

> 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?
> 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.
>   Or for projects
> that aren't as well known?
Again, in general, yes, because of the same reason.
> 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?

Best,

-Usama