Is there any benefit of doing this on the client side?<p>The message is sent through HTTPS anyway.<p>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.<p>This is redundant with HTTPS, but also useless if HTTPS is MITM.
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.<p>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.
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.<p>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?<p>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.<p>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.
Nice.. You can also do in browser client and sever side encryption now with <a href="https://www.noteshred.com" rel="nofollow">https://www.noteshred.com</a><p>See <a href="https://www.noteshred.com/client-side-encryption" rel="nofollow">https://www.noteshred.com/client-side-encryption</a>
I'd never seen SocialSharePrivacy either (It's linked in the page code), but it's an interesting idea:<p><a href="http://panzi.github.io/SocialSharePrivacy/" rel="nofollow">http://panzi.github.io/SocialSharePrivacy/</a>