Good morning,
I am student of math at the University of Padova, Italy. For the aim of my thesis,
I would like to know some datas.
On the total amount of the certificates let's encrypt releases, how many includes the use of elliptic curve cryptography, as ECDSA, ECDHE...? (An estimate percentage would be enough).
Thanks in advance for your answer,
Best regards,
Giulio Pozza
The quickest answer is that you can check yourself on some CT monitors
EG, on https://ct.cloudflare.com/ (filtering to ISRG, current, precerts):
Thank you @mcpherrinm ,
These are good datas. Anyway, in principle I was expecting a higher percentage of ecc compare to RSA, especially because in the key negotiation process ECDH(E) is much faster.
Thus I guess that most of certificates uses ECDH(E) over TLS1.3 protocol for the key exchange/negotiation part. Or am I wrong?
Those are two different things entirely. ECDHE does not use the ECC key used for the ECDSA process. You can do ECDHE with an RSA certificate without a problem.
Oh, there was a misunderstanding above, probably because of my improper use of "ecc" and "certificate" words .
My question about the uses of ecc in the certificates included both the key negotiation and the digital signature schemes.
Now, from your message and the cloudfare report, I am able to conclude that 20% of the certificates employ the ECDSA scheme, but I can't tell the percentage of certificates (RSA and ECDSA) that employ ECDH(E) in the key exchange.
Right now I can only guess on a high percentage.
It is not possible to tell what key exchange is used from the certificates alone. We don't have that data.
Key exchange would be up to the individual servers/devices if I'm not mistaken.
No expired certs? 
Ah... filtered by status of current.
That's because the browser and server will determine the key exchange used separate from the certificate entirely. So it's not possible to say "certificate that employs .. as key exchage", because they don't affect each other in modern cipher suites with forward secrecy.
Really interesting, indeed in TLS1.3 forward secrecy is mandatory, thus the ephimeral key exchange is separated form the certificate. Now I got it.
Thank you @mcpherrinm and @Osiris from your precious answers
I've done a little bit of extra digging for you. Chrome shared some data on the TLS working group mailing list last year which said:
....from the perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and
1.3, excluding 1.2 RSA), the breakdown is roughly:
15% P256
3% P384
56% X25519
26% X25519+Kyber
That's last year, I think X25519+ML-KEM (replacing Kyber) is probably higher now. https://radar.cloudflare.com/adoption-and-usage says that cloudflare sees 40% "Post Quantum Encrypted", which means X25519+ML-KEM
I've confirmed with poster that RSA key exchange is under 1%, and FFDHE is about zero.
So approximately all key exchange involves elliptic curve DHE
That's exactly what I was expecting from a math point of view: almost all the key exchange take place by ECDHE.
The percentage of the pqc implemented is something I can't tell, since I haven't deepen the argument. At first 40% surprised me since ML-KEM became a standard in the previous summer only. But considering the data you listed above (X25519+Kyber covering the 26%), and the push of Chrome in the direction of pqc implementation, then the percentages make sense.
That's very kind of you @mcpherrinm, your answer helped me a lot.
X25519MLKEM768 is around 76% for us currently on a large regional web application, as recent versions of Firefox, Chrome and Edge all support and prefer it. X25519 is at 24% (most other browsers), whereas P-256 and esp. P-384 are marginal for key exchange. This is counting only real users (logged in), not bots.
Edit: but I'm looking in the other direction, from a website that supports all of these, seeing what browsers support. The other post is about Chrome seeing what servers support (last year).
Ok, looking from a website point of view gives partcular and not general information, but these data say something too. Thank you.
I'm going to deepen on how Curve25519 works together with MLKEM, since right now I'm not into the kem argument, technically. Thus I will probably understand also the preferred choice of 2^9+2^8=768 key length on the MLKEM.
You can start reading here: The state of the post-quantum Internet
But keep in mind that this research post is from one year ago. The ML-KEM standard is there now, and the X25519MLKEM768 hybrid key exchange is implemented by major browsers and crypto libraries (and OpenSSL 3.5 which will be released this week), and already supported eg. by all Google and Cloudflare websites.
