Elliptic Curve Cryptography (ECC) Support

Nice! :slightly_smiling:

Too bad my lack of coding skills won’t help https://github.com/letsencrypt/letsencrypt/issues/2209 :stuck_out_tongue:

1 Like

You see that it was already implemented in https://github.com/letsencrypt/boulder/pull/1357 ?

1 Like

Boulder vs. client.

The issue I’m referring to is support in the client. The PR you’re linking to is for Boulder support.

1 Like

OK than it should be mentioned in the issue. “however there might be no support on the Boulder side at all yet.” sound for me Like an Boulder/Server issue.

1 Like

Yes, at that moment there wasn’t support in Boulder yet. But now that there is support, one could implement it in the client.

And no, why should it be mentioned in the issue? It’s clearly an issue in the letsencrypt / letsencrypt section, not in letsencrypt / boulder or somewhere else :slightly_smiling:

1 Like

I hope you’ll expand the supported elliptic curves to better ones like Curve25519 when they are finally support in current Browsers, because currently only some curves from the NSA Suite B are supported and they may be a bit flawed. If you follow these links and click a it through you can also find the specific tracking issues about this (at least for Firefox).

1 Like

From the Let’s Encrypt side of things, they’ll have to wait until the CA/B Forum permits other curves to bring them live. Right now section 6.1.5. of the Baseline Requirements limit all compliant CAs to the NIST curves. This is also reiterated in Let’s Encrypt’s CPS.

3 Likes

Okay. But when the curves are supported in the browser I assume it might not take long until it is also included in the CA/B Baselines.

3 Likes


6.1.5 Page 29 here are three EC types listed namely P‐256, P‐384 and P‐521
But the P-521 was rejected currently be LE.

And from the link (https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use) you mentioned

I’d say stick to secp521r1 - even DJB says P-521 is pretty nice prime, and it’s also supported in every modern crypto library.

So maybe this could be enabled at least ?

1 Like

It’s not supported in Chrome, though.

Speaking of, to quote rlb, “We need a caniuse.com for crypto.”

1 Like

secp521r1 is also the only ECC curve which has equal strength to 256 bits AES…

As encryption is only as strong as its weakest link, by disabling secp521r1, the use of 256 bits symmetric ciphers isn’t optimal: secp384r1 only provides security equal to a symmetric cipher of 192 bits. In effect, you’re loosing 64 bits of security… Which would be quite regrettable IMHO…

1 Like

Chrome isn’t the only browser out there as far as I’ve checked. :wink:

1 Like

The first thing we’d need there would at least be a listing of supported TLS protocol versions.

Afterwards we can think about elliptical curves:

2 Likes

Currently, the specification for EdDSA certificates (and Curve25519 ECDH for TLS) is under development by the IETF CURDLE WG. It’s going to be a long road until it’s ready for deployment; first the specification needs to get, well, not necessarily done, but stable enough that it can be implemented (consider that the ACME spec isn’t even finalized yet, but we have live implementations).

Then you need to add support to probably at least two TLS implementations (OpenSSL is more commonly used on the server side, and NSS more commonly on the client side; if you consider how long it took NSS to support TLS1.2…), and get a resolution in the CA/Browser forum allowing it to be used, and get support into Boulder (which will in turn require support in Go’s crypto libraries and CFSSL – so actually three TLS implementations), and clear whatever other policy hurdles will be in the way.

If you want Ed25519 account keys that will also require the Ed25519 for JOSE specification to become reasonably stable and support to be added to the Go implementation of it. If you want Ed25519 intermediates (as opposed to just ECDSA-signed Ed25519 subjects) you’d also need to procure HSMs which support Ed25519 signing, and it’ll probably be a long time before any such HSMs are even available. (Edit: I would also suspect that Let’s Encrypt won’t be able to source Ed25519 cross-signatures from their existing cross-signer, so the most expedient route would be to get an Ed25519 root installed in all root programs, which itself takes time, and that in turn assumes that root programme operators will by then have reached a resolution regarding inclusion of Ed25519 roots.)

TLDR: It is going to be a long time before Ed25519 is available, even assuming Let’s Encrypt has the desire to support it.

4 Likes

Thanks for the information… Now we can just hope for the future. :smile:

1 Like

That’s really a great idea.

I just moved from self-signed ECC to letsencrypt’s RSA. Hope I can use ECC again!:smile:

1 Like

As mentioned you can already do.

1 Like

It’s currently not yet in production, only in staging :wink:

Besides, it’ll be a RSA signed ECC public key containing cert :stuck_out_tongue:

1 Like

well it is signed by RSA but your server only has to sign using ECC which is good and for the client it is not much of a matter whether to verify RSA or ECC, because unlike a server a client usually doesnt handle many concurrent requests.

1 Like

from now this is included on standard
https://www.rfc-editor.org/rfc/rfc7748.txt

1 Like