> > (C) within the PQ part, providing alternatives that are less likely > to fail in the first place.` >
I think there is some more to say about what would make a good alternative KEM. Let's consider Saber. There are differences between ML-KEM and Saber. A simple implementation of Saber is less likely to have implementation mistakes such as Kyberslash. (On the other hand, a very fast implementation of Saber is more complex, but let's ignore that.) Performance is roughly the same, although of course we can point out some differences there (Saber is easier to mask). Although we can point out some differences, on the whole Saber is just too similar to ML-KEM. Most security issues will affect both Saber and ML-KEM. On the other hand, McEliece is quite different. It's unlikely a cryptanalytic advance will affect both McEliece and ML-KEM. Unfortunately McEliece isn't a generally viable drop-in replacement for ML-KEM for the ephemeral key exchange in TLS. BIKE and HQC are more realistic alternatives, but the gap in performance with ML-KEM is still significant. NTRU Prime has acceptable performance and it's farther from ML-KEM than Saber, but it's still a structured lattice and it still shares a considerable attack surface with ML-KEM. I think that if we pursue an alternative structured lattice KEM, it should bring at least another advantage to the table. From a performance perspective BAT ( https://eprint.iacr.org/2022/031 ) improves considerably over ML-KEM in certain use cases: its ciphertexts and public keys are smaller, but its keygen is slower. That's a good trade-off for non-ephemeral use cases such as ECH, AuthKEM, and OHTTP. Best, Bas
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
