On Sat, Jul 26, 2014 at 2:57 PM, Theodore Ts'o
On Sat, Jul 26, 2014 at 05:03:46PM +0200, Lodewijk andré de la porte wrote:
"WHAT'S THE "CHICKEN-EGG PROBLEM" WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY?
Somebody, please, give me something to say against people that claim JS client side crypto can just never work!
// ianG // It's like opportunistic security.. // It specifically defeats mass surveillance... This is a valuable thing. Yes, it's nice and helps. It just needs to come with better disclaimers. Otherwise companies/providers that remain silent on their threat models do nothing but tarnish themselves amongst those that know better. Such silence could backfire. Whether they get used as an bad example in security presentations, or something happens to one or more of their users they effectively sold (or gave) snakeoil to.
Like it or not, the vast majority of people are using some kind of web based e-mail, whether it's GMail or Yahoo Mail or Hotmail, or something else.
Please provide link to your source that breaks down Email use by HTTP, IMAP/SMTP and legacy POP. And their crypted versions.
I think it's a bit more complicated than you're making it out to be. Ultimately, the nearly all of the software that people run come from the network, at one time or another. Even if you are using gpg running on your linux laptop, where did you get your copy of gpg and the Linux OS? Odds are, you got it over the network.
The problem is the context of where in the network you got the software from, and who you're using it with, and who you're trying to keep in the dark. If your first install or subsequent updates are from your mail, storage, or comms central service provider, etc... that's a major and direct conflict of your security interests. It's why Matasano objects. You don't download your OS from your adversary. On the other hand, if you obtain and use the code independantly of your provider, or the code creates a disinterested decentral P2P infrastructure (Freenet, etc)... then you're in a much better position. You've inserted a layer of independance/abstraction. Similar to installing gnupg to use independantly... https://openpgpjs.org/ http://code.google.com/p/crypto-js/ You should be able to download openpgp.js from the code distribution point, read any audits, check the sig, locally load and permanently lock it into your browser from your plugins directory. And then mail providers should develop a consistant RFC based API from which you interact with them so you don't have to download whatever blob they claim you need. Directly trusting codeloading works fine for internal corporate environments. But it's a really bad idea elsewhere. Examples of careful differences in security model... Holds the keys https://www.hushmail.com/ Provides the code https://encrypt.to/ https://www.bitaddress.org/ https://brainwallet.github.io/ Browser addon (likely dependant on provider webmail scraping 'API': remember attempts to scrape providers that did not offer IMAP/POP.) https://www.mailvelope.com/ Standalone webclient https://whiteout.io/technology.html https://www.mailpile.is/ https://github.com/pagekite/Mailpile Standalone UI https://www.enigmail.net/