search

sfluhrer / ml-kem-security-considerations

This is intended to be the CFRG draft containing security considerations for ML-KEM
Other
2 stars 7 forks source link

Binding properties #10

Open dconnolly opened 3 hours ago

dconnolly commented 3 hours ago

Included an overview of binding properties for KEMs and for ML-KEM specifically.

@bwesterb @sophieschmieg might have opinions to improve the text

sfluhrer commented 3 hours ago

I do not believe that ML-KEM suffers from reencapsulation attacks. As such, I do not see the point in including an extended paragraph on them. Remember, this is not about KEM's in general, but ML-KEM specifically. A more targeted paragraph (which mentions only those concerns specific to ML-KEM would be more reasonable.

dconnolly commented 3 hours ago

I do not believe that ML-KEM suffers from reencapsulation attacks. As such, I do not see the point in including an extended paragraph on them. Remember, this is not about KEM's in general, but ML-KEM specifically. A more targeted paragraph (which mentions only those concerns specific to ML-KEM would be more reasonable.

The mention is a motivation for binding properties in general, and an earlier version of Signal PQXDH using a regular IND-CCA KEM was vulnerable to such an attack - they were saved by using an earlier version of Kyber, in part, but had to commit to more information in their AAD to mitigate it completely. They are relevant in how the recommended use of ML-KEM as now standardized in FIPS 203 is safe, but using another KEM in a similar way may not be (because IND-CCA is insufficient). We can pare it down though.

sfluhrer commented 3 hours ago

The other issue is that this is mainly advice for protocol designers (and to a lesser extend, implementors). If there is something they may need to be aware of (e.g. MAL-BIND-K-KT), we should explain what it is (in addition to pointing them to some academic paper they will have trouble understanding), when that threat is relevant, and how to mitigate that threat.

dconnolly commented 2 hours ago

The other issue is that this is mainly advice for protocol designers (and to a lesser extend, implementors). If there is something they may need to be aware of (e.g. MAL-BIND-K-KT), we should explain what it is (in addition to pointing them to some academic paper they will have trouble understanding), when that threat is relevant, and how to mitigate that threat.

Yes, that is basically done in the ML-KEM-specific section at the end