I support prohibiting key reuse, and a quick search shows several threads where this has been discussed before.
But concerning the issue at hand, I would love to hear about the application where amortization is worthwhile. It puzzles me that this is worthwhile. The thing is that ML-KEM keygen is very fast. On my old i7 laptop it's 18k cycles. That's faster than encapsulation (22kC) and decapsulation (22kC). This is not the whole picture even, as a typical TLS implementation will keep the matrix A around so that decapsulation does not have to recompute it. That reduces decapsulation to about 8kC. Are you perhaps generating ML-KEM private keys in a separate chip or HSM? Best, Bas On Tue, Mar 18, 2025 at 2:08 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Tue, Mar 18, 2025 at 05:30:36PM +0700, Kris Kwiatkowski wrote: > > > Thanks for reporting that (again). Indeed, I was hoping this text > > could be added to draft-ietf-tls-hybrid-design. > > > > Please, let me know if this text properly addresses your concern: > > > https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/35 > > I know that John has been quite vocal on this point, but does it actualy > reflect WG rough consensus? In > > > https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/35#discussion_r2000985130 > > I ask: > > Why not document the pros/cons and let implementations decide? Some > clients (server-to-server routine traffic) have no reason to, and > get no benefit if they do, avoid session linking. Why shouldn't > they amortise the cost of key generation via reuse of ML-KEM > ephemeral keys? > > -- > VIktor. > > _______________________________________________ > 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
