We have a requirement to encrypt data client side to ensure a ‘secure’ channel exists between our client’s browser and a vendor.
Basic premise is:
Vendor generates a public / private keypair: VendorPub and VendorPriv
Our clients enter sensitive data.
On submit the javascript on the form encrypts the sensitive portions of the data, what gets submitted to our server is VendorPub(SensitiveData).
We submit that package to our vendor as VendorPub(SensitiveData), only they can make use of that data.
Irrespective of key lengths and approved algorithms (RSA and 4096 respectively), and of course the whole thing would be over a SSL connection…
It looks doable, but I haven’t mocked it up yet… Any suggestions? Pitfalls?
Our development environment is Visual Studio 2k5/ 2k8 / ASP.net 2.0 or 3.0
Thank you
The other answers currently seem to have missed the point of this: “We submit that package to our vendor as VendorPub(SensitiveData), only they can make use of that data”. In other words, you are a relay who treats the data as a black box.
What you are describing is doable if the amount of data is not very large. Remember, you can’t keep the users waiting for your JavaScript to chug along.
RSA4096 is ridiculously huge, by the way. 2048 is high-grade at the moment and 3000-whatever is supposed to be good for 30+ years. But, more power to ya. A normal way to get around the public-key expense is to encrypt a symmetric (DSA) key using RSA – that way your encryption of the actual data is fast and the only slow part is decrypting the (shorter) key. Asymmetric-key encryption is much slower than symmetric.
Whatever you decide to implement, make sure you get the encryption right in the JS code.
You should also note that this isn’t really a way to protect the users from you; you control the web server, so you could send the users doctored JavaScript that delivers their private data to you with a key you control. The users would be unlikely to notice.