
How might the feds have snooped on Lavabit? - evo_9
http://arstechnica.com/tech-policy/2013/08/how-might-the-feds-have-snooped-on-lavabit/
======
FellowTraveler
\-- 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.

