crypto: fix EdDSA support for KeyObject

[mscdex]

Fixes: #26316

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[nodejs-github-bot]

@mscdex sadly an error occured when I tried to trigger a build :(

[targos]

@nodejs/crypto

[mscdex]

Also, this should be backported if/when #26270 lands.

[bnoordhuis]

Can you also check that encryption and decryption work? Search this file for publicEncrypt() and privateDecrypt() for examples.

(We really should have tests that check that all different KeyObject types are accepted wherever a KeyObject is accepted - e.g., sign(), verify(), createHmac(), etc.)

edit: oh, I see you opened #26320 for this?

[mscdex]

Correct, these changes were easy/straight-forward enough that I decided to submit a PR for them separately.

[sam-github]

Looks good.

The pre-existing switch statement default CHECK() makes me wonder if there are other key types that could be smuggled in to cause abort.

[mscdex]

CI: https://ci.nodejs.org/job/node-test-pull-request/21046/

[tniessen]

Sorry for chiming in late, I've been away for a couple of days.

[BridgeAR]

Ping @mscdex

[mscdex]

CI again: https://ci.nodejs.org/job/node-test-pull-request/21250/

[panva]

Aren't we just "patching" here? In the future if another key manages to pass openssl but isn't prepared this way we'll crash again.

[sam-github]

It's hard to know if this catches all key types that are possible, I don't understand enough of the context this is used, or the OpenSSL APIs.

A check of the OpenSSL headers don't make it easy to see what EVP_PKEY_ types we should handle:

node/deps/openssl/openssl/include/openssl/evp.h

Lines 41 to 64 in b22ee71

	# defineEVP_PKEY_NONE NID_undef
	# defineEVP_PKEY_RSA NID_rsaEncryption
	# defineEVP_PKEY_RSA2 NID_rsa
	# defineEVP_PKEY_RSA_PSS NID_rsassaPss
	# defineEVP_PKEY_DSA NID_dsa
	# defineEVP_PKEY_DSA1 NID_dsa_2
	# defineEVP_PKEY_DSA2 NID_dsaWithSHA
	# defineEVP_PKEY_DSA3 NID_dsaWithSHA1
	# defineEVP_PKEY_DSA4 NID_dsaWithSHA1_2
	# defineEVP_PKEY_DH NID_dhKeyAgreement
	# defineEVP_PKEY_DHX NID_dhpublicnumber
	# defineEVP_PKEY_EC NID_X9_62_id_ecPublicKey
	# defineEVP_PKEY_SM2 NID_sm2
	# defineEVP_PKEY_HMAC NID_hmac
	# defineEVP_PKEY_CMAC NID_cmac
	# defineEVP_PKEY_SCRYPT NID_id_scrypt
	# defineEVP_PKEY_TLS1_PRF NID_tls1_prf
	# defineEVP_PKEY_HKDF NID_hkdf
	# defineEVP_PKEY_POLY1305 NID_poly1305
	# defineEVP_PKEY_SIPHASH NID_siphash
	# defineEVP_PKEY_X25519 NID_X25519
	# defineEVP_PKEY_ED25519 NID_ED25519
	# defineEVP_PKEY_X448 NID_X448
	# defineEVP_PKEY_ED448 NID_ED448

I can only find one case statement handling EVP_PKEY_ED448, and it could be taken to imply we are missing a couple PKEY types that we should perhaps handle,EVP_PKEY_RSA_PSS, EVP_PKEY_DH, and the three Gost key types:

node/deps/openssl/openssl/crypto/x509/x509type.c

Lines 33 to 59 in b22ee71

	caseEVP_PKEY_RSA:
	ret=EVP_PK_RSA | EVP_PKT_SIGN;
	/* if (!sign only extension) */
	ret |= EVP_PKT_ENC;
	break;
	caseEVP_PKEY_RSA_PSS:
	ret=EVP_PK_RSA | EVP_PKT_SIGN;
	break;
	caseEVP_PKEY_DSA:
	ret=EVP_PK_DSA | EVP_PKT_SIGN;
	break;
	caseEVP_PKEY_EC:
	ret=EVP_PK_EC | EVP_PKT_SIGN | EVP_PKT_EXCH;
	break;
	caseEVP_PKEY_ED448:
	caseEVP_PKEY_ED25519:
	ret=EVP_PKT_SIGN;
	break;
	caseEVP_PKEY_DH:
	ret=EVP_PK_DH | EVP_PKT_EXCH;
	break;
	caseNID_id_GostR3410_2001:
	caseNID_id_GostR3410_2012_256:
	caseNID_id_GostR3410_2012_512:
	ret=EVP_PKT_EXCH | EVP_PKT_SIGN;
	break;
	default:

@mscdex Do you think its worth adding a couple more case statements to match X509_certificate_type(), or is that fn meant to handle a different situtation?

Its fine to leave that for a follow up PR if it takes more research. It is in my TODO list of things to look at, but that list is already large and growing faster than my free time, so no promises.

[mscdex]

@sam-github The only reason I'm adding these values is because ed25519/ed448 support was only added in OpenSSL 1.1.1, which was pulled in not that long ago. I do not know about supporting other types.

[sam-github]

@mscdex Understood. If anyone else wants to take a crack at figuring out what other types could show up in the default of the case statement, have at it, but I don't think it should block this PR.

[tniessen]

@sam-github I can take a look at that later, this PR should be good to land either way as you said.

[tniessen]

I just remembered we have most of our keys in test/fixtures/keys and a Makefile that generates them. We are not exactly consistent about that, there are also some keys in test/fixtures, I am not sure whether that was intentional.

[tniessen]

Unsurprisingly, ubuntu1604_sharedlibs_openssl110_x64 fails. How long do we need to support that platform? It should be enough to add a preprocessor #if around these cases since they cannot occur on older OpenSSL builds anyway. The test case will need to be adapted, though.

[Trott]

@sam-github Wherever the conversation is had, we do have a team for distributors (@nodejs/distros) and another for embedders (@nodejs/embedders) so maybe pinging those channels. They are both subteams of @nodejs/delivery-channels (which also includes the version management folks, for stuff like nvm and n). The delivery-channels team has no repository, but they do have a discussion board. Unfortunately, that can't be made public (but can be made viewable by anyone in the @nodejs org and that's hundreds of people, so maybe that's a place to start.).

[panva]

I think dont-land-on-v11.x is erroneously applied here. The other key types we landed without this label had their CI pass just fine.

[targos]

I just landed the commit on v11.x-staging.

[mscdex]

FWIW this was labeled as dont-land-on-v11.x because as-is it would mean v11.x would not be able to compile against a shared OpenSSL version prior to 1.1.1 and traditionally node has allowed such situations, so unless that policy has changed, currently the next v11.x release will break for anyone compiling it against OpenSSL 1.1.0 for example.

[sam-github]

Its pretty easy to add some conditionals on the key type so that it builds against shared openssl 1.1.0, so doing a backport is very possible if someone wants to.

[mscdex]

Honestly I'd much rather have all eddsa-related functionality available within a branch (even if it means it's only available in node v12+) because it's easier to think about, rather than having to a bunch of complicated checks.

[sam-github]

What do you mean by "branch"?

I'm not concerned about getting eddsa back into 10.x, if 10.x users want new features they can use 12.x.

However, in my experience, small "we won't backport this because we don't need the feature" changes have big ripples, as backports become increasingly difficult because new code has textual (as opposed to depending on eddsa) dependencies on the non-backported code. Eventually, more and more stuff has to be backported that could have cherry-picked cleanly, or almost cleanly.

[sam-github]

I'm not going to push hard for this to be backported, but I will propose a backport as soon as we have a PR that doesn't land because this is missing.

Required checks for backporting are an ifdef around the two new case statements, and some of the test keys have to be skipped. I don't think that is complicated.