问题
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
回答1:
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.
回答2:
It's definitely doable; although it might be a bit sluggish.
Here's a RSA implementation in JS: http://www.ohdave.com/rsa/
回答3:
There seems to be little (if any) reason to do any of this if you're going to use an SSL connection (though I'd prefer TLS).
If you decide to do it anyway, the biggest pitfall with PK cryptography is a MITM attack -- i.e., you don't want to just accept the server's key and encrypt data with it. That will ensure that only the server can read the data, but if you haven't verified the identity of the server, you could be sending it to somebody else entirely. This is most of why 1) SSL/TLS connections are slow to set up, and 2) SSL/TLS libraries are big and complicated. Encryption is much easier than authentication.
There's no more reason to do this yourself than to do encryption yourself though -- SSL/TLS already do both authentication and encryption.
回答4:
Ok, so the end answer is: It's doable, reasonably fast and reasonably secure. However as this was a PCI requirement with the intent to de-scope our environment it was failed because we would still own the encryption method, IE the javascript that would do the encryption would be served from our system.
Thanks to everyone who chimed in.
Gary
来源：https://stackoverflow.com/questions/3355160/client-side-encryption-any-recommendations-best-practices-point-me-in-the