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: 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
