On Monday, 6 January 2025 09:49:35 CET, Viktor Dukhovni 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.
I suspect that we would have people using it tomorrow if we had shipping
code.
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
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
