Hi There,
Im reading here: (looks no)
But here: (looks yes)
So which one is correct?
ThX!
Unfortunately, no. I guess the CP just lists all the theoretical possibilities so legally speaking they've got everything covered. However, in practice, P521 is not enabled in the ACME server.
That said, Chrome/Chromium also doesn't support P521 and with Chrome, neither does Chromium-based Edge.
3 Likes
I see thats weird, Wonder why is that? (doesnt make alot of sense to not support it)
Do you have evidence on that?
Looking here:
https://boringssl-review.googlesource.com/c/boringssl/+/2843/4//COMMIT_MSG#9
We only implement four curves (P-224, P-256, P-384, and P-521) and only
advertise the latter three by default. Don't maintain entries corresponding to
all the unimplemented curves.
So i think p-521 supported no?
Additional, Mozilla FF rejected this request:
Interestingly, there appear to be exactly zero (trusted) P-521 leaf certificates in the wild. No CA is willing to issue them yet, apparently 
.
5 Likes
https://bugs.chromium.org/p/chromium/issues/detail?id=478225
P-521 is essentially dead, compatibility-wise.
5 Likes
3 Likes
I see, what a stupid decision by chrome.. oh its google..
Thanks guys for the evidence, But what about Lets Encrypt?
Afaik what google do has nothing to do with which algorithm i want to use for my cert? (unless lets encrypt is based on google decisions)
So rejecting/not implementing support for better encryption has nothing to do with which browser supporting it or not, Imagine i want to use my own browser or wait guess what there is an entire organization called mozilla (which produce FF) support this feature so i dont get it, does anyone has justification for lets encrypt for not doing it?
Well if a CA did use P-521 anywhere in the chain I believe Google Chrome would fail the cert.
And Google Chrome is THE dominant force in the Web Browser arena
U.S. and global browser market share 2023 | Statista.
So I doubt there is much value for Let's Encrypt or any CA to offer P-521.
1 Like
NIST high-level over view of Suite B
1 Like
But I would be happier if SHA3 family of secure hashes would be pulled in by the CA/Browser Forum followed by safer curves for elliptic-curves, see here for my comments When choosing an elliptic-curve look for a safe curve
3 Likes
Good post totally agree, But sadly seems to be ignored/no body gonna do something because of the big brother chosen something else.
NSA or NIST or Market Share is nonsense, Because LE can support it and only few use it that has no contradictions (LE has nothing to loose as they say)
Afai can say the rejection of implementation is because of google/chrome which is rejected that based on (somewhat) Suite B which is made on the NSA decisions which one good and which one bad... hmm..
Thats bad guys, But anyway until now no justified reason to not support it and let the users decide to use it or not. (because im not asking to make it the default but only as an option)
One of P-256 or P-384 is strong enough, and is faster than larger curves. If you’re worried about the strength of P-384, then the Let’s Encrypt PKI is not appropriate since our ecdsa roots and intermediates are P-384.
Supporting any new algorithms comes at a cost, and there’s no reason to support P-521. P-256 is strong enough for any use case within the lifetime of a Lets Encrypt certificate. Any credible threat to P-256 is likely to come in the form of either significant breaks to ecdsa or quantum computing, either of which are just as likely to break P-521
7 Likes
P-521?
P-384 is plenty overkill already! It's nearly equivalent to RSA with 15k keys. And it's very slow when compared to P-256.
I don't even want to imagine how much slower P-521 would be.
1 Like
Great answer, I do agree also, Protocols has flaws (PAA/SPAA..) and if there are better methods then it will effect the entire protocol regardless which algorithm we gonna use..
I hope you document my question with your answer in your wiki, Thank you brother.
Thank you guys, Best helping forum i faced since long time.
God Bless.
1 Like
Nah, P-384 is equal to a RSA key size of about 7680 bits ("security strength" of 192, e.g. AES-192). ECC with 512+ keysize (e.g. 521) would be equivalent to a RSA key of at least 15 360 bits and a "security strength" of at least 256. See table 2 on pages 54 and 55 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf (PDF page 67 and 68).
So effectively, using AES256 is overkill when using P-256 or P-384. And P-384 is overkill when using AES128.
Personally, I'd like to have my AES key strength and ECC key strength equal. However, currently you can't use AES192 with any (relevant) software implementation as far as I know, so P-384 is useless IMO. If there is an option to use AES256, I would like to have P-521 available. Or Goldilocks x448/Ed448.
I don't have a good word for the devs at Google and/or Go (which is Google too I guess).. They refuse to implement P-521 as wel as x448/Ed448.
4 Likes
In fact there is! AES was standardized with 128, 192, and 256 bit key sizes, all with a 128 bit block size. Rijndael, which AES is a standardized form of, is capable of having more options in both dimensions but only three forms were standardized.
Relatedly, this is a good blog post covers some of the material we've already discussed in this thread, including some discussion of why you likely don't need P-521 for anything: Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022 - Dhole Moments
8 Likes
That might be, but software implementations and/or RFCs (OpenSSL, Chromium or even TLS-1.3 for example) don't support it, it seems. I'll edit my post to reflect 
From the post:
If you’re choosing P-521 in your designs, you’re basically saying, “I want to have 256 bits of asymmetric cryptographic security, come hell or high water!” even though the 128-bit security level is likely just fine for your actual threats.
I can live with that 
4 Likes
The motivation for 256-bit keys with AES is to resist quantum attacks in the future (Store Now, Decrypt Later). But our key exchanges aren't post-quantum yet, so until they are, attackers can just store the handshake and obtain the keys.
Once we have post-quantum TLS handshakes, 256-bit AES offers 128 bits of PQ security, while 128-bit AES only offers 64 bits of PQ security. This isn't a trivial difference; the thing being halved is an exponent.
If you want to use AES-128-GCM with P-256 or P-384 for TLS today, that's fine. You're at no greater risk to quantum computers, and you side-step a 40% performance penalty on a very, very fast operation (which makes it still fast but not as fast as it could be).
Using P-521 is just silly, though: Nobody (to my knowledge) has constant-time P-521 code. Not OpenSSL, for sure.
Choosing "bigger key size" over "more likely to be implemented securely" is a weird decision. A bigger key size won't matter if you're coughing up your signing key to anyone who cares to ask for it. ECDHE is less likely to be affected here, but with an ECDSA signing key, you can just MitM the server.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.