On Mon, Jan 06, 2025 at 08:00:04AM +0000, Kris Kwiatkowski wrote:
> On 06/01/2025 06:18, Viktor Dukhovni wrote:
> > it would be very unlikey to get
> > used.
> The addition of that codepoint was previously discussed on this mailing
> list, and as Victor says,
> it is unlikely to be used.
Sure, but for the record the same applies to SecP3841MLKEM1024, which is
slower still and also not especially compelling. A more complete table:
keygen encaps decaps keygens/s encaps/s
decaps/s
ML-KEM-768 0.000027s 0.000017s 0.000027s 36852.5 57951.3
36580.9
ML-KEM-1024 0.000042s 0.000023s 0.000036s 23865.3 43257.8
27478.9
X25519MLKEM768 0.000054s 0.000071s 0.000056s 18638.2 14051.3
17725.6
SecP256r1MLKEM768 0.000042s 0.000076s 0.000075s 23747.7 13224.7
13406.0
X448MLKEM1024 0.000226s 0.000337s 0.000172s 4427.6 2967.8
5807.0
SecP384r1MLKEM1024 0.000690s 0.001292s 0.000674s 1449.2 773.9
1483.9
Though it looks a bit better with the GCC 128-bit arithmetic
optimisations (OpenSSL's "enable-ec_nistp_64_gcc_128") enabled:
SecP384r1MLKEM1024 0.000176s 0.000495s 0.000362s 5673.4 2022.1
2763.8
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
