Support parsing pem key only once for crypto api

[tlbdk]

Current API parses the PEM files on every crypto operation, fx:

• https://nodejs.org/api/crypto.html#crypto_class_sign

• node/src/node_crypto.cc

  Line 4168 in 0d22858

  pkey = PEM_read_bio_PrivateKey(bp,

I would be nice if this could be done once and a ref to the openssl key could be retained:

const crypto = require('crypto');

// Read and parse key once
const privateKey = crypto.readPrivateKey(getPrivateKeySomehow());
// privateKey would be a ref to the PEM_read_bio_PrivateKey() pointer

for(let i = 0; i < 10000; i++) {
  const sign = crypto.createSign('RSA-SHA256');
  sign.write('some data to sign' + i);
  sign.end();
  console.log(sign.sign(privateKey, 'hex'));
}

[seishun]

I don't like passing an opaque object to the sign method, and introducing a "parsed key" class would increase complexity. I think it would be a cleaner API to allow passing the PEM key to createSign and allow reusing the resulting Sign object.

[tlbdk]

@seishun This get a bit problematic to use when you are streaming data as what it seems the current API is build for. I'm guessing the hash is being incrementally calculated when doing the 'write' calls and the 'sign' call then encrypts that to provide the signature.

The example below shows a sample where using a shared sign object would give an unexpected result:

const crypto = require('crypto');

// Create shared sign object
const sign = crypto.createSign('RSA-SHA256', getPrivateKeySomehow());

// Start taking requests.
const server = http.createServer((req, res) => {
  req.on('data', (chunk) => {
     // Here we are mixing data between the requests
     sign.write(chunk);
  }).on('end', () => {
     sign.end();
     response.end(sign.sign(privateKey, 'hex'))
});
...

Most other languages have a "parsed key" class as there are many different ways signing can be done, fx. both C# and Java can use different underlying signing implementations fx. when using HSM devices or running on other platforms where the key material is not a available to application. Fx. C# uses windows certificate store on windows, keychain on mac and openssl on Linux. Java use a hardware backed keystore on Android, etc.

Having someone kind of abstraction would make the whole key handling a lot more flexible, fx. imagine using a hardware backed keystore for storage of the private key.

For inspiration here is how the API looks in Java, it's similar to Node with the exception that you pass a key object so it's only constructed once.

PrivateKey privatekey =  customPemToPrivateKey(getPrivateKeySomehow())
for(let i = 0; i < 10000; i++) {
  Signature signature = Signature.getInstance("SHA256withRSA");
  signature.initSign(privatekey);
  signature.update(String.getBytes("some data to sign" + i, StandardCharsets.UTF_8));
  byte[] signatureBytes = signature.sign();
}

And here in C# where the "key" in the focal point of the interface, so the "key" object has a sign function.

SHA256 sha256 = SHA256.Create();
RSACryptoServiceProvider privatekey = customPemToCryptoProvider(getPrivateKeySomehow())
for(let i = 0; i < 10000; i++) {
  byte[] signatureBytes = privatekey.SignData(Encoding.UTF8.GetBytes("some data to sign" + i), sha256);
}

[tniessen]

cc @nodejs/crypto

I'd like to revive the idea. After having worked on the crypto module a lot recently, I think having key objects could actually be advantageous for us:

• Once a key has been created, it is guaranteed to be valid and not malformed.
• Currently, users need to keep the passphrase for encrypted PKCS#8 keys or the unencrypted key in JS-managed memory which isn't optimal from a security point of view. Having key objects would allow us to protect the memory, see crypto.alloc() for encryption key memory management #18896.
• We would finally be able to work with keys stored in engines! (see Support parsing pem key only once for crypto api #15113 (comment))
• A crypto key API would allow users to seamlessly convert between PKCS#1 / SPKI and PKCS#1 / PKCS#8 / SEC1 and even between PEM / DER.
• All existing APIs can be adapted to support key objects.
• The way we currently handle keys is a mess, to be honest, and having key objects could greatly simplify that.
• Key objects would play nicely with the API being designed in crypto: add key pair generation #22660.
• A carefully designed key API would allow users to implement the JWK key format rather easily compared to the current situation.

I am currently trying to assess some API drafts, I'll let you know when I have a proposal.

[tlbdk]

@tniessen this would also enable us to work with keys stored outside the nodejs process, fx. in keychain on mac, certificate store on Windows, GNOME Keyring on linux, TPM (Trusted Platform Module) or HSM's (Hardware Security Module) like Yubikey, TouchID, smartcards, etc.

Fx. if we stick with openssl it can be extended with an engine config: https://developers.yubico.com/YubiHSM2/Usage_Guides/OpenSSL_with_pkcs11_engine.html

[tniessen]

this would also enable us to work with keys stored outside the nodejs process, fx. in keychain on mac, certificate store on Windows, GNOME Keyring on linux, TPM (Trusted Platform Module) or HSM's (Hardware Security Module) like Yubikey, TouchID, smartcards, etc.

@tlbdk Will that require support for custom key objects (user-defined classes)? That would make a secure implementation more difficult.

[tlbdk]

@tniessen No, not if the implementation detail is left to OpenSSL fx using its engine API to add the different HSM backends, it already has the needed abstraction.

There is already API for setting the engine:

https://nodejs.org/api/crypto.html#crypto_crypto_setengine_engine_flags

But we need an API to load keys from engines:

• https://www.openssl.org/docs/man1.1.1/man3/ENGINE_load_private_key.html
• https://github.com/OpenSC/libp11/blob/09b4b9c6253ca5d2868f0685675d91ad98a512c1/tests/rsa-pss-sign.c#L137

fx.

const privateKey = crypto.readEnginePrivateKey("keyid"); // This would just be a wrapper around the openssl key ref 

The key object class could have the same the suggested conversion methods but would just return null when the engine does give access to the underlying key data.

[tniessen]

@tlbdk Awesome, thanks for the clarification.

[tniessen]

@tlbdk I proposed an API in #24234, for now, it does not support engine key objects, but we can definitely add support later once the API has been established.

[tlbdk]

@tniessen Looks really good, thanks for working on this :)

[tniessen]

Key objects have landed. Please let us know whether there is a feature you would like to see that is still missing. (Loading keys from engines is not supported yet.)