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

[Martin Schanzenbach <[e-mail]>]

Hi,

Hello,

I want to preface my answer for the record that I also agree with the 
notion that a single, secure combiner for any IND-CCA2 KEM is the most 
prudent choice and currently this appears to be a strange situation 
where what seems most logical/conservative is "tacked on" to this draft 
and has no/little application while the ML-KEM-tailored combiner is 
preferred for efficiency reasons that do not convince me. However, I 
have outlined my concerns in previous (significantly older than this 
thread) more detailed emails already and they are in the archive. I 
really do not want to rehash everything already said.

To answer one of Muhammads questions (even though it was not directed at 
me):

Am 11.07.26 um 09:11 schrieb Muhammad Usama Sardar:
>
> Hi Richard,
>
> Without taking any position, a couple of notes and clarifying 
> questions below:
>
> On 11.07.26 04:53, Richard Barnes wrote:
>> This message is a reply to D. J. Bernstein, but not directly on 
>> account of not wanting to run afoul of his copyright lawyering
> I don't think you need this line. One can see who you are replying to.
>> Then how do you explain, e.g., CVE-2017-0379?
> Without going into any detail, please note that you are pointing to a 
> decade-old CVE. Could you please clarify your motivation for pointing 
> to such an old CVE?
>> 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).

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.

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. Which 
is why Richard said "No cryptographic algorithm can prevent *all* 
software bugs." (Presuming I am correct in that interpretation)

BR


> Best,
>
> -Usama
>
>
> _______________________________________________
> CFRG mailing list [e-mail]
> To unsubscribe send an email [e-mail]