Use `crypto.webcrypto.*` functions to be compliant with the Web Crypto spec

[MichaelDeBoey]

https://nodejs.org/dist/latest-v20.x/docs/api/crypto.html#cryptosubtle

CC/ @natevw

[natevw]

Put some notes on https://github.com/tj/node-cookie-signature/pull/50#issuecomment-1686685907 as well, but as far as this feature request generally I think my question would be: what's the use case?

My understanding is that cookie-signature should be focused on that, signing cookies which would need to be done on the server-side where the engine is presumedly Node.js and no need for Web Crypto compatibility. Assuming node.js doesn't plan to deprecate their old crypto module any time soon, is that correct?

[MichaelDeBoey]

@natevw My goal was to make this a first step towards full Web Crypto compliance (using the crypto global instead of the Crypto API), so that this package could be used on other runtimes like Bun, Cloudflare and/or Deno as well

• https://bun.sh/docs/runtime/web-apis
• https://developers.cloudflare.com/workers/runtime-apis/web-crypto
• https://deno.land/api@v1.36.2?s=SubtleCrypto

[natevw]

Yeah, that does seem useful at least in some library. But the code here is basically two tiny functions that have worked ± the same for over a decade.

@dougwilson is the Express framework moving to support other runtimes besides Node.js? Otherwise I'm inclined to decline this work here, and leave improvements like this available to a new npm package that can have a fresh start in the modern JS era.

[MichaelDeBoey]

@natevw The end-result of these changes will be exactly the same as it was without these change, it's only an internal change of using different APIs But it has the added benefit of being usable with Bun, Cloudflare and Deno (and other runtimes that support the standardized Web API) as well

[nexdrew]

If anyone's interested, I recently published a new package called cookie-signature-subtle that does exactly what @MichaelDeBoey is asking for - it's basically cookie-signature using the Web Crypto API (which is async) - because I had a similar desire to support other non-Node web-standard runtimes. (Apologies for the shameless plug, just trying to help!)

[natevw]

@nexdrew No apologies needed, thanks for sharing! Seems to match exactly my hope that someone could make a fresh start without the backwards compatibility constraints. If more people end up needing this we could probably update the README as well (and perhaps there's other similar libraries in the space…).