Hi all, I’m looking for a clojure/clojurescript crypto solution. I want to encrypt a payload with a public key in the browser, then decrypt it on the server. I found the javascript browser namespace for the Web Crypto API, and I have been using buddy on the server for a while now. But I cannot seem to find an asymmetric scheme that works in both places. Specifically, the Web Crypto API says the RSA-OAEP is the only asymmetric scheme for encryption (vs sign, etc) and even though buddy has a large number of RSA variations, none seem to correspond to RSA-OAEP. Any suggestions? I’m open to options outside of buddy and the web api, but I’d prefer not to import a library just for this functionality.
isn’t buddy mainly for auth? what you are doing sounds pretty custom - ie small payloads, client initiated encryption and the easiest way to get it working is to use node on the backend to make sure the right encryption scheme is in place before worrying about integration.
You should be able to implement something along the lines you are after using Java interop and the java.security API with the Bouncy Castle provider (https://www.bouncycastle.org/). See this example RSA example with OAEP Padding and random key generation. : RSA algorithm « Security « Java Tutorial However, I’m not sure if this is really the right approach for what you are doing as you say you want to encrypt a payload in the browser and decrypt it in the server. Why? More specifically, why is HTTPS not sufficient? Your description essentially sounds like a ‘roll your own’ version of how HTTPS works. Of course, this would be a bad idea due to how hard it is to get it right.
An important bit of unknown information is how keys are managed in your application. How is the public key provided to the browser?
In general, you probably want to use just symmetric encryption for your payloads because of various performance benefits over asynch encryption. The strength of public key is in being able to verify actors. A more typical workflow is to establish the parties are who they claim to be using public key encryption and then negotiate between the two on an acceptable cipher to use for payloads and finally, exchange the key to be used for that cipher.
So I guess the key question is “Why do you require asymmetric public key encryption?” What are the risks your addressing and how does it reduce them over using symmetric encryption or just relying on the encryption inherent in https? Keep in mind, the major contributing factor for security weaknesses is complexity. It is critically important to be confident that additional layers of security are adding more security than what is potentially lost from additional complexity.
1 Like
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.