2
$\begingroup$

We are trying to generate some self-signed certificates to test our cybersecurity firmware before switching to a "real" CA-signed chain of trust. The specification we are coding to mandates that the keys are to use ED25519 and the certificates are to be signed with EDCSA-with-SHA256. We are working with OpenSSL 1.1.1q (5 Jul 2022).

The supplier provided us a sample certificate that when analyzed with OpenSSL 1.1.1q follows this rule (redacted excerpt below):

openssl x509 -in Verify.pem -text
Certificate:                                        
    Data:                                       
        Version: 3 (0x2)                                        
        Serial Number: 17 (0x11)                                        
        Signature Algorithm: ecdsa-with-SHA256                                      
        Issuer: CN = theSupplier                                        
        Validity                                        
            Not Before: Jun  9 08:30:35 2022 GMT                                        
            Not After : Jun  6 08:30:35 2032 GMT                                        
        Subject: CN = theXXX, serialNumber = XXX
            
        Subject Public Key Info:                                        
            Public Key Algorithm: ED25519                                       
                ED25519 Public-Key:                                     
                pub:

We are able to generate ED25519 keys without any issue but I cannot find a way to convince OpenSSL to generate a self-signed certificate with ECDSA-with-SHA256 as the signing algorithm.

openssl req -x509 -new -nodes -key root_priv_key.pem -sha256 -days 365 -out root_cert_test.crt

openssl x509 -in root_cert_test.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            31:b4:ec:ca:c9:98:16:77:29:93:69:84:fe:ab:1c:b8:49:9a:d9:ed
        Signature Algorithm: ED25519
        Issuer: CN = testCert
        Validity
            Not Before: Jul 22 13:14:06 2022 GMT
            Not After : Jul 22 13:14:06 2023 GMT
        Subject: CN = testCert
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:

I understand that OpenSSL doesn't consider ED25519 as part of its elliptical algorithm suite (i.e. we use genpkey and not ecparam) so I guess it assumes RSA for the signing algorithm. (If we self-sign a certificate using prime256v1, for example, it will show the signing algorithm as ECDSA-with-SHA256.)

Is there a way to make OpenSSL sign with ECDSA-with-SHA256 when signing an ED25519 certificate? Do we need to use a different toolchain? A different key?

$\endgroup$
1
  • $\begingroup$ Why are you trying to require ECDSA signatures from EdDSA keys? They're not meant to be used like that. $\endgroup$ Jul 23, 2022 at 12:04

1 Answer 1

2
$\begingroup$

Your 'sample' cert is NOT self-signed -- the issuer and subject are different. OpenSSL can do that. If you really do want self-signed INSTEAD:

No OpenSSL doesn't 'assume RSA'! Ed25519 and Ed448 (and X25519 and X448) are elliptical-curve algorithms, but different from the X9-standardized Weierstrass ones implemented by the older (since 0.9.x) OpenSSL routines named EC_* etc. EdDSA and XDH are also implemented in the crypto/ec source module (in libcrypto) but by separate routines, which being designed more recently follow the new policy of exposing only a 'pmeth' API through EVP, not a 'direct' low-level one, which makes them visibly different.

Because to OpenSSL they are different algorithms, it can't use the key(s) from one in another.

Weierstrass curves exist equivalent to Ed25519/X25519 and Ed448/X448. As well as some Qs here, and many other places, they are defined (with the names W-25519 and W-448) in NIST's draft-since-2019 SP800-186 which if adopted along with also-draft FIPS186-5 would presumably allow their use in ECDSA (since X9.62 has reportedly been withdrawn leaving FIPS186 as the standard) -- which may cause Bernstein to explode, since (AFAICT) it destroys the safety and robustness benefits he sought to provide.

OpenSSL does not have this builtin, but it allows you to define arbitrary Weierstrass parameters and you could do so with the ones from SP800-186 (although I'm not sure there's an OID you can use). It certainly doesn't implement the point mapping that would allow an ECDSA-W-25519 signature to be verified with an Ed25519 publickey, and I don't know anything else that does either. OTOH verifying the signature on a self-signed cert is mostly meaningless; OpenSSL never does so by default, so this inability may be okay, and I've not confirmed any other implementation doing so besides Windows.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.