Hi,
I think it is very hard to get any reliable statistics on what is the most
popular curve in the world. I agree with you that X25519 is now used in the
vast majority of TLS handshake on the Web, which is great. But curves are used
outside of TLS, and TLS is a lot bigger than just the Web, and popularity can
be interpreted differently.
The two things I love about X25519 is its speed and that there is no need to do
point validation in most cases. There have been a huge amount of practical
vulnerabilities due to implementations not doing point validation. My feeling
is that there is still a worring amount of deployed implementation that do not
do point validation. Solutions to this are X25519, including some part from
point the point validation calculation in the key derivation, and negative test
vectors. I strongly hope that NIST will have a large amount of negative test
vectors for the PQC algorithms and that FIPS validation require failing these.
Positive test vectors are for interoperability, negative test vectors are for
security.
I think X25519+ML-KEM should be the first choice for hybrid key exchange, but
there is also a need for curves with higher security. There are as I see it two
reasons to do hybrid:
1. Protect against potential future theoretical attacks on lattice- or
code-based crypto
2. Protect aganst bad implementations of lattice- or code-based crypto. My
understanding is that the side-channel protection of many current
pre-standardization implementations are quite bad.
If you are doing hybrid for reason number 1, and you are currently using P-384
or P-521 to get a higher security level, you likely want to continue to use
P-384 or P-521. X448 is to my understanding not as supported as X25519.
>NSA's harder-to-implement approach to ECC
I think the NIST P-curves are well-designed for being published in 1998. I
think NSA should have credit for designing and pushing adoption of ECC. I wish
that the world would had followed Suite B (2005) and completely moved to ECC.
Unfortunatly we still have to deal with RSA and FFDH.
Cheers,
John
From: D. J. Bernstein <d...@cr.yp.to>
Date: Sunday, 2 June 2024 at 20:48
To: tls@ietf.org <tls@ietf.org>
Subject: [TLS]Curve-popularity data?
Information about the popularity of specific cryptosystems plays a role
in decisions of what to standardize and deploy. I've been pointed to a
surprising statement (quoted below) regarding popularity of curves, in
particular in TLS handshakes. The statement is from one of the current
TLS co-chairs, a month before the co-chair appointment. I'm wondering
what data the statement is based on; the statement doesn't have a
description of the data sources, and the statement seems impossible to
reconcile with various public statements that have clear data sources.
A specific reason that I'd like to resolve this is that I'm concerned
about the impact on post-quantum deployment. To explain:
* We're failing to protect confidentiality of most user data against
future quantum attacks---but switching to a post-quantum system has
an unacceptably high chance of making security even worse. See
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23qrcsp&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123054408%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=aJEyMJ505bdg7b%2BMePETQui%2FVgcYmTt7%2FQpMomMuXBA%3D&reserved=0<https://cr.yp.to/papers.html#qrcsp>
for how much has been broken.
* The obvious path forward is to immediately roll out ECC+PQ hybrids,
as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701
in ALTS, X25519+kyber768 in
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cloudflare.com%2Fpq-2024&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123061366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WzfdrqSiWT%2B6BCVXMbE2qKb9E9tmy1RBc1fX81vqtSo%3D&reserved=0<https://blog.cloudflare.com/pq-2024>,
X25519+kyber512 in
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengineering.fb.com%2F2024%2F05%2F22%2Fsecurity%2Fpost-quantum-readiness-tls-pqr-meta%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123066403%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=292CeJkqAaXFq7ZzOXHWXXYQP%2BlbaTxlrrFF79rwmg0%3D&reserved=0<https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/>,
etc. Then we're not making security worse, and _hopefully_ we're
making it better.
* This still leaves the challenge of minimizing post-quantum risks.
That's hard enough without the combinatorial explosion of combining
each post-quantum option with a profusion of curves. Adding many
curve choices is the sort of thing that _sounds_ simple until you
start writing software, tests, etc. (I designed X25519 after
suffering through implementing an example of NSA/NIST ECDH; see
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fnistp224.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123070251%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rmLakdBU3ZfXm6a%2BezRV4KD%2BCu6BKu0cR9tq8uDx378%3D&reserved=0<https://cr.yp.to/nistp224.html>
and the accompanying talks. NSA's
harder-to-implement approach to ECC also ends up more likely to
fail later; see, e.g.,
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cr.yp.to%2F20191024-eddsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123073993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vECEsoslTjh04xdmmthlhNSDvqtE4sbVChav%2BVDEWw8%3D&reserved=0.)<https://blog.cr.yp.to/20191024-eddsa.html>
Here's the specific statement I'm asking about:
P 256 is the most popular curve in the world besides the bitcoin
curve. And I don’t have head to head numbers, and the bitcoin curve
is SEC P, but P 256 is most popular curve on the internet. So
certificates, TLS, handshakes, all of that is like 70 plus percent
negotiated with the P 256 curve.
Last I heard, _certificates_ hadn't upgraded to allowing Ed25519 yet.
My question is about the "handshake" claim, and more broadly about the
"internet" and "world" claims.
Examples of why I find the above TLS-handshake claim surprising:
*
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cloudflare.com%2Ftowards-post-quantum-cryptography-in-tls%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123077705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1RkLGrQpmZF6373sF8glcTn%2F5qYNB2IrcE%2FeoXzKG38%3D&reserved=0<https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/>
(2019) says that "the most commonly used key exchange algorithm
(according to Cloudflare's data) is the non-quantum X25519".
*
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cloudflare.com%2Fpost-quantum-for-all%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123081435%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GbWi4Cry0sKiqiLufOrV1vZAnQKVi6uAeGHvre5ZEEU%3D&reserved=0<https://blog.cloudflare.com/post-quantum-for-all/>
(2022) says that
"Almost every server supports the X25519 key-agreement and almost
every client (98% today) sends a X25519 keyshare."
*
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2023%2F734&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123085090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5Sh66Ue%2BTnNrZLlai5q81w1rK%2FF8WwHpK3ukig3QNtE%3D&reserved=0<https://eprint.iacr.org/2023/734>
recorded TLS connections from many
different apps and noted that X25519 was used in "the vast majority
of the recorded handshakes".
*
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cloudflare.com%2Fpq-2024&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123088715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=edkM3M9myHFpOOj5ncDyHFskNXnHAFxbvcbjKZI34aY%3D&reserved=0<https://blog.cloudflare.com/pq-2024>
says "Today almost all traffic
is secured with X25519, a Diffie–Hellman-style key agreement".
* The handshake simulations in, e.g.,
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ssllabs.com%2Fssltest%2Fanalyze.html%3Fd%3Dgoogle.com%26s%3D142.250.217.142%26hideResults%3Don%26ignoreMismatch%3Don&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123092367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tgt96TltHxByPQslqvZ56P3p8itWFtZTpf%2Ftso312Ns%3D&reserved=0<https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=142.250.217.142&hideResults=on&ignoreMismatch=on>
show current browsers using X25519 (while showing older client
software using P-256). Clicking on random servers listed on the
same site also consistently shows X25519.
To be clear, this isn't saying that _all_ handshakes are using X25519.
NIST didn't manage to standardize Ed25519 until 2023, and still hasn't
managed to standardize X25519, so probably it's not too hard to find
servers that insist on P-256 for "FIPS compliance". I figured I'd be
able to give easy examples of this by trying nist.gov and nsa.gov---
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20240602150722%2Fhttps%3A%2F%2Fwww.ssllabs.com%2Fssltest%2Fanalyze.html%3Fd%3Dnist.gov%26s%3D129.6.13.49&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123095973%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6j5iQRIB1nQ%2BEms9eJleIoNtD6TSJnNt1wtoJYX%2FGjk%3D&reserved=0<https://web.archive.org/web/20240602150722/https://www.ssllabs.com/ssltest/analyze.html?d=nist.gov&s=129.6.13.49>
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20240602151119%2Fhttps%3A%2F%2Fwww.ssllabs.com%2Fssltest%2Fanalyze.html%3Fd%3Dnsa.gov&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123099875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z8tL49zlH7AK0BY3WCw6pqt5eiGUvtSXVpBn5gnpVtg%3D&reserved=0<https://web.archive.org/web/20240602151119/https://www.ssllabs.com/ssltest/analyze.html?d=nsa.gov>
---but it turns out that both of them end up using X25519, unless you're
connecting to nsa.gov with a client that doesn't support TLS 1.3.
More broadly, Nicolai Brown's pages
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fianix.com%2Fpub%2Fcurve25519-deployment.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123103587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7RJ9zcNIheOdijW55rFyoTegEyTV4acVPsTdq0GzsPk%3D&reserved=0<https://ianix.com/pub/curve25519-deployment.html>
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fianix.com%2Fpub%2Fed25519-deployment.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123107398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DnvwXTpcRQxzUTY1WcDQLUnCDDsb90MLyLwzMm0%2F%2B7Y%3D&reserved=0<https://ianix.com/pub/ed25519-deployment.html>
include a long list of applications of X25519 and Ed25519. Spot-checks
confirm the overall accuracy of the list, and find many applications
where Curve25519 is the only curve, including big applications such as
WhatsApp and WireGuard.
I'm also aware of some applications where P-256 is the only option. I
would guess that
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecurity.apple.com%2Fblog%2Fimessage-pq3%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123111956%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rqNQBz6BbxloXIA2WWIjKgpIga5Mtl6FReS5K26QEu4%3D&reserved=0<https://security.apple.com/blog/imessage-pq3/>
is now
the biggest P-256 application. But I don't know how one would reach a
conclusion that "P 256 is most popular curve on the internet".
---D. J. Bernstein
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
