X25519 cert and difficulty with manual generation

Server
1

I’m trying to avoid prime256v1 in favor of X25519 and getting nowhere fast. It’s running OpenSSL 1.1.x and nginx is compiled against that, openssl ecparam -list_curves shows nothing in 25519, but it does appear in openssl list -public-key-algorithms (which apparently is normal). Which means openssl ecparam doesn’t like being told to use X25519.

So first question would be how to generate an X25519-capable cert.

The second question applies to every single time I’ve tried to manually generate a letsencrypt cert. While this server does have two standard auto-generated certs, this one cert I’m trying to generate is for literally for only one subdomain, and no matter which guide I follow I wind up with

Unfortunately, your CSR needs to have a SubjectAltName for every domain

I’ve tried using [SAN} and not using [SAN] in openssl.cnf with the

subjectAltName=DNS:…

added just below it, and that doesn’t make any difference at all. There were several other methods with the same lack of result.

This is Ubuntu 16.04.2LTS, I’ve tried both OpenSSL 1.1.1-dev and OpenSSL 1.1.0d, no difference, and nginx 1.11.9 using ssl_ecdh_curve ‘X25519:secp521r1:secp384r1’ which passes configtest.

2

I think Let’s Encrypt only supports “prime256v1”, “secp384r1” and “secp521r1” for private keys.

3

Not even secp521r1 @serverco :slight_smile: https://github.com/letsencrypt/boulder/blob/master/goodkey/good_key.go#L172-L183

4

I must double check … I thought that it was only “prime256v1” or “secp384r1” for the account key, but it could be any of the 3 for the domain private key. I may well be wrong :wink:

5

You are correct @Osiris :slight_smile: - my memory must be going, I’m sure I’ve got certs before using secp521r1 as the private key - I tested all types though and that one does give an “Invalid Key in cert” error.

6

It has never been enabled for subject keys.

But perhaps this is going to change: Allow secp521r1 ECDSA signing (all obstacles were solved) · Issue #2217 · letsencrypt/boulder · GitHub

7

That confirms the memory had gone :smiley:

I knew I’d added it to my getssl script for some reason - must have been because of the proposal for the future, rather than available in the past. Thanks for finding that and saying though :slight_smile:

8

I went ahead and did the secp384r1. Hopefully we can get X25519 support in at some point considering the amount of speculation about P-256 and P-384 already being compromised.
thanks!

2 Likes
9

None of the speculation is from professional cryptographers. Ed25519 is better than P-256 ECDSA, but that's because the state of the art has improved in the last 20 years, not because it's likely the NSA curves are backdoored.

10

Curves other than P-256, P-384, or P-521 are currently not allowed by the Baseline Requirements. The CA/B Forum is probably waiting for the EdDSA/Ed25519 TLS spec to go through the IETF process before allowing those. Once that happens (and once HSM and browser vendors add support for the curves in their products), Let’s Encrypt may start supporting these curves.

1 Like
11

It’s supported in Chromium browsers (and in use on at least Wikipedia and Google) so I’m not sure about the requirements. DJ Bernstein is a cryptographer and concluded the P-256 cipher isn’t safe to use, most likely less due to its strength than it originating in NIST/NSA. I see enough concern going back four or more years among security experts and cryptographers – including the NSA itself – to dieprecate P-256 and Suite B. Hopefully it happens in a more timely fashion, IETF takes forever.

12

That's x25519, the Diffie-Hellman "version" of Curve25519. Ed25519 is going to be used for EdDSA, a "variant" on ECDSA for use in signatures.
Thus, for using Curve25519 in certificates, we need to have Ed25519, not x25519 :wink:

BTW, Curve25519 only offers 128 bits of security :anguished: I'd rather have 256 bits TBH.

13

I was going by OpenSSL’s terminology, apparently it’s not enough to have x25519, edd25519, and Curve25519, we also need X25519 as well (though it seems to have no functional application, edd25519 works fine with 1.0.2 and I can’t seem to see a function for X25519 in OpenSSL 1.1 except to smile at me). As I understand it, and I’m no cryptographer, the curve ciphers are able to achieve stronger security than RSA ones that are much larger (I think it was 128bit = 7860bit RSA, I read somewhere) which also results in faster key exchange.

14

Quantum computers will probably eventually fry both. :scream:

A 128-bit "security level" (256-bit ECDH/ECDSA/EdDSA) roughly corresponds to 3072-bit DH/RSA. The estimates for a 192- or 256-bit security level for DH or RSA vary wildly in size and degree of impracticality.

You can check out https://www.keylength.com/ for some numbers.

I'd guess you're thinking of the NIST comparison that 7680-bit RSA provides a roughly 192-bit security level.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.