[fooyc]

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.

[mschuster91]

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.

[fooyc]

If your browser is untrusted, you are doomed.

> Furthermore, this helps against content disclosure if the server is compromised.

If the server is compromised, openpgp.js is compromised too.

[willvarfar]

Presuming the private key for the messages is not on the server, then old messages will not be compromised.

A kind of perfect secrecy for messages.

[fooyc]

No need to do this on the client side then (that was my point)

[willvarfar]

You could do the exact same thing on the server, but that's using server's CPU instead of clients?

[manojlds]

Forward secrecy with https? https://community.qualys.com/blogs/securitylabs/2013/08/05/c...

[willvarfar]

yeah its often called perfect forward secrecy - PFS - too.

http://en.wikipedia.org/wiki/Perfect_forward_secrecy

[StavrosK]

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.

[jis]

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....