Async crypto functions

[dhensby]

I note previous replies on this topic here and here. I also note these replies are over 2 years old and there is now support for an async node crypto.

However, I'd like to put forward an argument for supporting async crypto functions in NodeJS - or rather, support for custom signing/verifying functions.

It is becoming an increasing requirement that applications perform cryptographic operations using external key management services such as AWS KMS and Azure Key Vault - this allows non-exportable private keys, possibly backed by Hardware Security Modules, to be used to perform cryptographic operations externally to the application memory.

In these circumstances the application has no access to the secret material and so cannot pass it to node's native crypto functions. Instead, a REST API or similar interaction must be performed to obtain the output and this is an async operation.

At the moment this library supports the fact that signing and verifying operations are asynchronous, the final piece of the puzzle is to allow some way to replace the built-in node crypto integration with a provided operation.

There could be a couple of ways to do this:

1. Have some interface for a more generic "key" - instead of using KeyLike type, an internal key type could be created that can hold references to how it performs signing/verifying and this could be provided to the library by a consumer allowing signing to be handed-off to an external service.
2. Add sign/verify callbacks to the SignOptions/VerifyOptions that are passed to the sign/verify functions, when these are supplied they could be used in place of the runtime functions.

[panva]

Async crypto functions

Async crypto APIs are already used when available in a given runtime. Moving the public API to a Promise based one was a prerequisite given that Web Crypto API is entirely async anyway.

external key management services

I do not plan on adding support for this. Replacing CryptoKey / KeyObject / Uint8Array "KeyLike" is not what the internal validations could easily change.

These services also only IMO come into play when producing signed tokens, since you're always able to export the public key material and have that available in your process. Then, when it comes to signing, forming the signing input is an easy task, one can argue you don't necessarily need a library for it in the first place given you're proposing you'd be providing the code that actually obtains the signature.

[dhensby]

I agree that the primary use-case here is signing and that verifying is usually not a problem (as you point out) because the public material is indeed public so can be held in memory.

I understand that there is a fair amount of work involved in replacing the KeyLike type, though if there was some agreement on an approach I'd be happy to contribute development effort to this.

One way of thinking of this is less about "supporting external KMS" but more as being slightly less tightly coupled to the "runtime" crypto and allowing a crypto package to be augmented or even provided externally. This would enable more flexibility around the crypto functions which would then also happen to facilitate consumers that need to use a KMS.

As for arguing that there wouldn't be a need for this library if the signing aspect was performed by a KMS - I don't agree. We're talking about replacing this call (and others like it) with a call to an API instead of to node's crypto or the browser's webcrypto. All the other library code would remain and provide value in terms of constructing the signatures/tokens/etc.

---

Edit: Accidentally hit submit too early

[panva]

The effort required to develop and maintain this needs to be compared to what boils down to be these few lines of your own code.

const header = { alg: 'PS256' }
const payload = { sub: 'foo' }
const signingInput = base64url(JSON.stringify(header)) + '.' + base64url(JSON.stringify(payload))

const signature = await kmsSign(signingInput)

// if this is an ECDSA signature use https://www.npmjs.com/package/ecdsa-sig-formatter

const jwt = signingInput + '.' + base64url(signature)

Edit: And what it would ends up being in the library would be just a foot gun for the uninitiated.

[dhensby]

Thanks a lot for taking the time to respond so promptly and setting out your viewpoint.

Of course, I'd like to be able to use the library with first-class support for what I need to do, but I understand your point of view.