Is there any benefit of doing this on the client side?
The message is sent through HTTPS anyway.
If HTTPS was compromised, the javascript code signing the message, and the signing key, and everything related to handling the clear text message would be compromised too anyway.
This is redundant with HTTPS, but also useless if HTTPS is MITM.
This can protect against malicious browser extensions recording POST/GET-transmitted data (toolbars!!!), as the content will be encrypted at that stage.
Furthermore, this helps against content disclosure if the server is compromised.
Eh, it might be a bit useful if there's a passive adversary on the server. They can read traffic, but not change anything. Pretty unlikely scenario, so it doesn't really buy you much.
Your cloud hosting provider can easily be a passive adversary. Altering your data is risky for them (you might notice) so they won't alter your copy of openpgp.js or the public keys you use. But looking at all of your disk and memory and network is something they can do and you would never know. But if the private key is not on the server, they will never be able to decrypt the messages encrypted for you....
The page loads jquery from google cdn, so at least google could inject js in the page and read the message before it gets encrypted.
I know, for a contact form this is very unlikely, but just from a security point of view, if I would write something like this, I would host js loaded by the page on my own server.
I've been wondering about web crypto, and how you can actually be protected from say Google getting your content before it's actually encrypted in the browser. Could Chrome's recent "packaged apps" help with that? Maybe if that part of the web app/extension was actually native/offline (but still inside the browser), it would be secure against that. Of course then you have to start wondering whether Google didn't implement a backdoor inside the browser itself...but maybe the fact that Chromium is open source can help there.
I've been wondering about web crypto, and how you can actually be protected from say Google getting your content before it's actually encrypted in the browser.
Just don't load third party js from a domain you don't own, use tls and you are good.
This idea (encryption in javascript in a regular web browser) comes up very often on HN. It's not a good idea. Since I have no way to trust/verify that the encryption code itself has not been tampered with (beyond HTTPS) then it is only secure as HTTPS.
You've added a fair bit of complexity for no specific benefit; likely a net loss in terms of security.
I'm not sure what this adds over applying PGP on the server?
The way to intercept the message with the server doing PGP would be to either MITM the connection or breach into the server to intercept before encryption.
In both cases you could just as well modify the javascript served to the browser to defeat the PGP done in the browser as well.
it adds not much. it does make it more complex to intercept because you need to serve diff js. il also means cleartext isnt on the server at all til compromised.
but yeah the design is bypassable. thus not really safe. clients should do it natively i guess.
The message is sent through HTTPS anyway.
If HTTPS was compromised, the javascript code signing the message, and the signing key, and everything related to handling the clear text message would be compromised too anyway.
This is redundant with HTTPS, but also useless if HTTPS is MITM.