On Sun, Oct 12, 2025 at 4:52 PM John Mattsson <john.mattsson= [email protected]> wrote:
> > I think the draft should discuss the performance differences. This is > likely very important for readers of the document. For optimized > implementations, X25519MLKEM768 is significantly faster than > SecP256r1MLKEM768 which is significantly faster than SecP384r1MLKEM1024. > And as optimized ML-KEM is significantly faster than X25519, they are all > significantly slower than standalone ML-KEM. > https://blog.cloudflare.com/es-es/pq-2024/ > > Performance is practically an extremely important security factor as slow > performance often lead to violated requirements. > Performance characteristics tend to change over time as implementations and hardware capabilities evolve. For example, with s2n-bignum backed crypto on a modern server CPU I observe that ECDHE X25519 is faster than ML-KEM-768 on both client and server side if keypairs are generated dynamically for each handshake. Given this variability across software and hardware environments, I would be hesitant to include specific performance guidance in what is intended to be a relatively stable specification. That said, it might be worthwhile to add a note in the Security Considerations section about potential DoS implications when enabling more computationally expensive key exchange mechanisms. -yaroslav -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
