Open ethndotsh opened 10 months ago
This sounds like a good idea, the main hurdle that I see for it currently is that the Node.js cryptography API is synchronous, while SubtleCrypto is async, so the visitor system would have to be converted first to async.
The underyling library used for encryption, @47ng/cloak
also has support for SubtleCrypto, so it may not be necessary to go for providers in this case.
Alright, sounds good! If cloak has support for SubtleCrypto this should be simple, right?
The asyncification of the visitor pattern might require some work to be done in a performant way (possibly running it in parallel, with a careful balance between memory usage due to the Promises overhead and total execution time per query), but it's a necessary step for making it more flexible in the future.
Would you like to try your hand at a PR?
Apologies for the delay. Unfortunately I am very busy this time of year with finals in school, and work. Thank you for the offer but I won't be able to work on a PR right now, sorry.
Hello, i was doing some fiddling with the package and was initially just trying to make it work with the SubtleCrypto @47ng/cloak and I replaced encryptStringSync, decryptStringSync, makeKeychainSync, parseKeySync with encryptString, decryptString, makeKeychain, parseKey respectively that uses the SubleCrypto.
But my traceback shows that the /src/encryption.ts is still making a reference to some object in @47ng/cloak/dist/message.js where Node.js crypto module has been used. Am I missing something? A little direction would be helpful.
That is odd.. Perhaps @franky47 knows why?
@47ng/cloak
is not particularly well adapted to those newer edge runtimes with SubtleCrypto support, it would need some polish to support this use-case first before an update can be used here.
Namely, feature-detecting SubtleCrypto support based not on the presence/absence of window
. This would however only solve half of the problem, the other half being that the processing code to encrypt/decrypt data is synchronous and would need to support async operations (see my previous comments).
Prisma has just started letting some users test out a version of Prisma compiled to WASM so that it can run on the edge. I've tested it myself and it looks really promising, yet one problem I have encoutered is that it does not work with prisma-field-encryption yet because of prisma-field-encryption's reliance on Node.js's crypto module which is not available in edge contexts.
My suggestion is to have 'crypto providers' for different contexts, similar to what Stripe does with their Node.js module (see: https://github.com/stripe/stripe-node/tree/master/src/crypto) to support edge contexts. My thinking is that when instantiating prisma-field-encryption, you pass in a crypto provider that works for where you are running Prisma (likely just SublteCrypto and node:crypto are all that is required)
Let me know what you think!