Hubert Kario wrote: >1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20 times >faster than P-384
Yes, P-384 is a bit unoptimized. That will change in newer versions. But still much slower than P-256 which in turn is much slower than X25519 (which is slightly slower than ML-KEM). https://sthbrx.github.io/blog/2023/08/07/going-out-on-a-limb-efficient-elliptic-curve-arithmetic-in-openssl/ >2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm, it does >not include X25519 as an approved algorithm. Yes, that is a shame. I don’t think NIST ever gave any reasoning behind this. >3. we're likely years before we will get first FIPS certified ML-KEM >implementation Yes >so I expect that most regular servers will use x25519+ML-KEM, the ones >that have a requirement for FIPS compliance will have to use P-256+ML-KEM, >and the ones that have Common Critera requirements will have to use >P-384+ML-KEM. I assume servers with Common Critera requirements would likely want to use P-384+ML-KEM-1024. I would also very much like X25519+ML-KEM-512 for use cases where message size matters. ML-KEM-512 public keys are smaller than ML-KEM-768 which means that you can fit X25519+ML-KEM-512 in a single packet without fragmentation. I have quite high trust in ML-KEM from a theoretical perspective. The margin to known attacks is large. I don’t have much trust in implementations. Early implementations might have both bugs and significant side-channel leakage. I think implementation aspects is the main reason to do hybrid. Cheers, John From: Hubert Kario <hka...@redhat.com> Date: Wednesday, 5 June 2024 at 13:20 To: Stephen Farrell <stephen.farr...@cs.tcd.ie> Cc: John Mattsson <john.matts...@ericsson.com>, tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] [EXTERNAL] Curve-popularity data? On Wednesday, 5 June 2024 09:19:51 CEST, Stephen Farrell wrote: > > On 05/06/2024 06:56, John Mattsson wrote: >> I think P-384 is the most required of the NIST P-curves. > > I've heard that some. Oddly, I use a test server that only supports > p384 as a way to trigger HRR when testing ECH, which seems to work for > most clients who test with my servers, so I wonder if, when using a > hybrid KEM, we're heading to a world where one large set of clients > emit x25519 and x25519+pq and another large set emit p256 and p384+pq? > > I guess if that meant there wasn't a real need for much use of p256+pq > that might be a small saving and worth documenting somewhere even if > we do define a codepoint for p256+pq. 1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20 times faster than P-384 2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm, it does not include X25519 as an approved algorithm. 3. we're likely years before we will get first FIPS certified ML-KEM implementation so I expect that most regular servers will use x25519+ML-KEM, the ones that have a requirement for FIPS compliance will have to use P-256+ML-KEM, and the ones that have Common Critera requirements will have to use P-384+ML-KEM. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb70f391217844d5e8cc308dc855179ec%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638531832177835328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=grHoVU8T5RN6n6a0GnVYun63svZhKjSqLu10AH%2BQc0E%3D&reserved=0<http://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
