Dang, Quynh wrote: >My guess is that that would be an expensive operation because of many reasons.
Yes, and to make sure that the first two keys were not just before and just after a rekeying, you would need to look at three keys… While any timing side channels in X25519MLKEM768 are hopefully mitigated by the hybrid construction, this is not true with standalone ML-KEM. For standalone ML-KEM, it is even more important to forbid reuse of encapsulation keys when communicating with several peers. Also, standalone ML-KEM is even faster than the already very fast X25519MLKEM768, so there is even less justification for any reuse. Cheers, John From: Dang, Quynh H. (Fed) <quynh.dang=40nist....@dmarc.ietf.org> Date: Monday, 10 March 2025 at 14:09 To: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt The server can detect a reused encapsulation key if it saves the keys which have been received and check the newly received key against the list of its saved keys. The server could just save the hashes of the keys or a "small" portion of the keys as the key IDs. My guess is that that would be an expensive operation because of many reasons. Regards, Quynh. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
