Add more worktop/crypto helpers

[lukeed]

As of #11, there is now a worktop/crypto module that includes the following helpers:

• digest(algo, message)
• SHA1(message)
• SHA256(message)
• SHA384(message)
• SHA512(message)

This ticket exists to collect suggestions for additional helpers that should be added to the module, if any.
So far, I think these would be good additions, if for no other reason than type safety:

declare function importkey(secret: string, algo: ALGO, scopes = ['sign', 'verify']): Promise<CryptoKey>;
declare function verify(secret: string, algo: ALGO, message: string): Promise<ArrayBuffer>;
declare function sign(secret: string, algo: ALGO, message: string): Promise<ArrayBuffer>;

Additionally, I have a PBKDF2 implementation that I can extract from existing application(s) and generalize it:

declare function PBKDF2(input: string, salt: string, iterations: number, keylen: number, digest: string): Promise<ArrayBuffer>;

What else should be here? 🙏

---

Lastly, WRT importkey, verify, and sign specifically – my applications' implementations only made use of a "raw" imported key:

// example
crypto.subtle.importKey('raw', ....);

Is/Was this application-specific? Or is this "the norm" for a Workers environment?

My hesitation is that these utilities will be too reliant on my importKey assumption/default and be incorrect for a larger audience.

Thanks!

[ajwild]

I looked into this a while back and created jwebt so that I could send logs from Cloudflare Workers to GCP logging (with the help of jwebt-gcp). I used "pkcs8" rather than "raw". I'm not sure what the norm would be, and it's been almost a year since I worked on it, but at the time I didn't find a lot of information about best practices.

[lukeed]

Thanks! Yeah the next building block here is a worktop/jwt module, which I have ready to go, but again – not sure if the patterns/choices I made were specific to me.

Your links are helpful, but I think you and I are in the same position, wondering if/when different key-types are preferred. 🤷‍♂️

[ajwild]

While worktop is still "young" I'd say go with whatever works for your use case right now, but make it easy to extend. I just set some defaults based on what I needed, but allowed everything to be passed as parameters. I'm looking forward to giving this framework a go!

[lukeed]

Let me know how it fares for you!

It's young, but I still want to avoid breaking changes as much as possible. I have 3-5 new modules' worth of code I can add but I'm shopping around for feedback before adding anything. I don't think it'd be a nice early-adopter experience to be trying something new & having to rework parts of your application on every new release.

[mattwebbio]

Super excited about this project! Thought I'd cast my vote since it doesn't look like you've gotten much feedback here.

I'm planning to verify and decode JWT keys created/signed from an external application with an x509 public cert. Currently accomplishing this (outside worktop) with jsrsasign. Your suggested additions in the first comment look great!

[lukeed]

Thanks @mattwebbio! Yeah, there will definitely be a worktop/jwt. Still working through the knowledge gap of importKey so that I'm not setting everyone up for limited use cases.

[ajwild]

Would wrapping something like node-jose make more sense now that Cloudflare Workers (partially) supports node modules? Or is your intention to keep dependencies to an absolute minimum at this point?

https://blog.cloudflare.com/node-js-support-cloudflare-workers/
https://workers.cloudflare.com/works

[lukeed]

I already have the code for this, and I'd 1000% rather use native APIs already available within the runtime. The entire framework is a pure Workers target. Relying on Node.js shims is a forced dependency on extensive tooling (eg, webpack or an involved, custom shim setup) and/or reliance on a platform feature which isn't fully formed yet.