Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work on the edge with crypto providers #96

Open
ethndotsh opened this issue Jan 13, 2024 · 7 comments
Open

Work on the edge with crypto providers #96

ethndotsh opened this issue Jan 13, 2024 · 7 comments

Comments

@ethndotsh
Copy link

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!

@ethndotsh ethndotsh changed the title Work on the edge Work on the edge with crypto providers Jan 13, 2024
@franky47
Copy link
Member

franky47 commented Jan 14, 2024

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.

@ethndotsh
Copy link
Author

Alright, sounds good! If cloak has support for SubtleCrypto this should be simple, right?

@franky47
Copy link
Member

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?

@ethndotsh
Copy link
Author

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.

@pingSubhajit
Copy link

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.

@ethndotsh
Copy link
Author

That is odd.. Perhaps @franky47 knows why?

@franky47
Copy link
Member

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants