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

On 11.07.26 12:20, Martin Schanzenbach wrote:
> To answer one of Muhammads questions (even though it was not directed 
> at me):
I apologize for not making it so clear. Sending it on the list (rather 
than off-list to an individual, for example) was implicit indication 
that all RG participants are welcome to share their insights. Thanks for 
sharing yours by drawing a very clear distinction between /algorithm/ 
and its /implementation/. I found that very helpful. I assume by the 
latter you mean algorithm implemented in a specific protocol, such as 
TLS. Please see inline.
> Am 11.07.26 um 09:11 schrieb Muhammad Usama Sardar:
>> On 11.07.26 04:53, Richard Barnes wrote:
>>> No cryptographic algorithm can prevent all software bugs.
>>
>> Could you please explain this one in more details at a level that a 
>> non-cryptographer like me can understand? Does it mean that 
>> cryptographers know ways to break /any/ cryptographic algorithm?
>>
> Yes, and no. We know how to break RSA, for example, in 
> sub-exponential, but also not polynomial time (=efficiently). So in 
> theory, it can be broken. In practice, this only matters when choosing 
> the parameters. Another as of today theoretic threat is the 
> cryptographically relevant quantum computer using Shor's algorithm to 
> break RSA.
>
> Some cryptography provides statistical or even information-theoretic 
> security guarantees. In such cases we can prove that is impossible or 
> unlikely that it can be broken. Most asymmetric assumptions do not 
> fall into this category (like the RSA assumption or DH assumptions, or 
> the Lattice-based assumptions). We cannot prove that the required 
> properties hold (hence "assumptions"). The longer an assumption holds 
> under the scrutiny of mathematicians and cryptographers, the better we 
> understand it and the more trust we have that it will not be broken in 
> the future. (Hence the whole hybrid discussion because ML-KEM or 
> rather the assumptions behind it are just not as well studied as 
> elliptic curve cryptography).
>
Thanks for the clarification, but this raises a paradox in my mind. How 
are we supposed to evaluate the documents in RGLC when the only way to 
build trust in the assumptions is to put them to the test of time? 
Please apologize my naive questions. I work at symbolic level (in 
ProVerif) and I am trying to understand what kind of feedback would the 
RG find most helpful for the RGLC.
>
> But what Richard probably meant is that even if the cryptographic 
> algorithm is perfectly secure (by whatever metric we want to apply) 
> and our assumptions hold, this does not help if your implementation of 
> the algorithm, as an extreme example of a bug, posts the secret key on 
> X whenever you use it.
>
Thanks; that distinction was very helpful.
>
> Now, CVE-2017-0379 refers to a bug (=implementation deficiency) 
> related to side channels. Algorithms can be carefully designed (or 
> improved) in order to reduce the surface area where such attacks could 
> get exploited in their implementation. This means that any measure 
> taken in the algorithm against side-channel attacks protect the 
> implementer from accidentally introducing such a bug. In my extreme 
> example of a side-channel key leak no algorithm modification can 
> protect you.
>
Could you please clarify that the keys here refer to the shared hybrid 
secrets between the two endpoints (e.g., server and client for TLS)? 
Even in your extreme case, I believe side-channel key leak of one secret 
key for a good implementation should not cause any problem because of 
hybrid composition property. IMHO, the system should remain secure 
unless /both/ keys are leaked.

Besides, my other question still stands: what is so special in 
this/decade old/ CVE? 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?

Best,

-Usama