[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,

Thanks for the clarifications. I've one more clarifying question. Please 
see inline:

On 13.07.26 00:09, D. J. Bernstein wrote:
> 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
Thanks, that's helpful for me.
> The newer evidence is further confirmation of the patterns covered in
> the 2019 posting, and matches the predictions we made years before that.
Thanks.
>> 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.

When you say "models," can I think of it as follows: say we have a /new/ 
algorithm A. You predict failures (somehow; I don't know how you will do 
that because it is /new/) and then you keep testing it over time, and 
improving those models. Is it roughly correct? If not, could you please 
clarify that in simple words without using fancy cryptographic terms?

For a cryptographic proof in CryptoVerif, probabilities are used for the 
primitives. I am trying to understand if this failure prediction has got 
anything to do with that.

>> 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?
Not at all, I was just thinking of a problem of the criteria. It was a 
general question about the criteria, not at all intended for Minerva 
vulnerabilities.
>>> 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.

Sure, that's why I said "In general."In [0], I mentioned how we found 
some deadly attacks in open-source project Cocos AI via formal analysis. 
Such an analysis would not have been possible if that was closed-source 
project.

Best,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/cfrg/7g2dDvhA_PtbHr2NCxvYEjSH1fA/