-- Even if the key is never STORED in decrypted form on the server, it still EXISTS in decrypted form during a brief moment when your password is used to decryp

-- Even if the key is never STORED in decrypted form on the server, it still EXISTS in decrypted form during a brief moment when your password is used to decrypt that key. -- Therefore the server COULD get your key, though it chooses not to store it. -- In fact, the server could get your PASSPHRASE too, if it is indeed used on the server side to decrypt that key. -- The only way to get around this is to ONLY store/use the key on the CLIENT side. This way, the server never has the ability to access the key or passphrase. (Nor the need to.) -- Services that provide client-side encryption tend to do so using a Java download app which runs on the client side. (And which runs in the browser.) A similar thing can be done using Javascript crypto which is also downloaded to, and executed on, the client side. -- For the NSA to get your key/password, they would simply serve your email provider with a warrant forcing them to ship you a trojan Java app, or trojan Javascript. (This is likely what they did with Lavabit.) -- To get around this, you'd need an installed crypto application on the client, instead of using downloadable browser-side crypto. (Which would probably mean it can't run inside the browser, but only as a separate application.) -- The solution we are using for Open-Transactions is an installed systray app on the client side, which can run in a protected space, combined with separate, thin-client plugins for Chrome, Firefox, Skype, etc, which send the crypto requests on to the systray app where the actual work is performed.