How about having x448mlkem1024 allocated as an experimental codepoint for those who wish to use it ?
On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > 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 _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
