crypto: always accept private keys as public keys

[tniessen]

Some APIs already accept private keys instead of public keys. This changes all relevant crypto APIs to do so.

As a nice side effect, this also allows to derive public keys from private keys using the new KeyObject API.

I am not 100% sure whether this is the best way to go, so I would love opinions from @nodejs/crypto or other people! Allowing private keys to be passed to verify makes sense in my opinion, but what if the user passes a public and a private key (both in the same PEM string) to createPublicKey? With this change, the public key would be used, but we should make sure to be on the same page about this.

Checklist

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

[nodejs-github-bot]

@tniessen build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2061/pipeline

[bnoordhuis]

Technical contents of the PR LGTM % a rebase.

what if the user passes a public and a private key (both in the same PEM string) to createPublicKey? With this change, the public key would be used

Personally, I'd expect it to use the private key as that's the ultimate source of truth.

[sam-github]

one tiny suggestion on the doc text, but otherwise LGTM

[tniessen]

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

[addaleax]

Landed in ae2d1f0

[panva]

Hi @tniessen

Not sure if this is related to the nightly node build i'm using or a bug with the implementation, i tried crypto.createPublicKey with various inputs.

In essence if i pass a private key loaded from the filesystem it works fine, but when i pass an existing instance of PrivateKeyObject it 💥

> ko=crypto.createPrivateKey(fs.readFileSync('ec.key'))
PrivateKeyObject { [Symbol(kKeyType)]: 'private' }
> crypto.createPublicKey(fs.readFileSync('ec.key'))
PublicKeyObject { [Symbol(kKeyType)]: 'public' }
> crypto.createPublicKey(ko)
/Users/panva/node-nightly/bin/node[66757]: ../src/node_crypto.cc:3168:node::crypto::ManagedEVPPKey node::crypto::GetPublicOrPrivateKeyFromJs(const FunctionCallbackInfo<v8::Value> &, unsigned int *, bool): Assertion `args[*offset]->IsObject() && allow_key_object' failed.
 1: 0x10006310d node::Abort() [/Users/panva/node-nightly/bin/node]
 2: 0x10006303f node::PrintErrorString(char const*, ...) [/Users/panva/node-nightly/bin/node]
 3: 0x100114f0b node::crypto::GetPublicOrPrivateKeyFromJs(v8::FunctionCallbackInfo<v8::Value> const&, unsigned int*, bool) [/Users/panva/node-nightly/bin/node]
 4: 0x1001142e8 node::crypto::KeyObject::Init(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/panva/node-nightly/bin/node]
 5: 0x1002240dd v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo*) [/Users/panva/node-nightly/bin/node]
 6: 0x100223696 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/panva/node-nightly/bin/node]
 7: 0x100222d90 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/panva/node-nightly/bin/node]
 8: 0x100e1ee6e v8_Default_embedded_blob_ [/Users/panva/node-nightly/bin/node]
 9: 0x2c2c9f40816e 
10: 0x2c2c9f40816e 
11: 0x100d8e2a3 v8_Default_embedded_blob_ [/Users/panva/node-nightly/bin/node]

[tniessen]

@panva Mhhh weird, that should throw in the JS layer. I'll have a look at it tomorrow, I wanted to add support for that operation anyway.

[tniessen]

Thank you for reporting this, @panva! Fixed in #25562.

[panva]

no problem, @tniessen the fix suggests that this operation is not intended, is that not intended "yet" and it'll be supported in the future?

[tniessen]

@panva It is not intended yet, I'm trying to improve the API in small incremental changes, allowing to derive public key objects from private key objects is one of those.

[panva]

Great, thanks for the heads up! I appreciate the changes you're making, what you call small incremental changes are huge leaps in nodejs crypto usability.