On Sat, Jul 26, 2014 at 2:57 PM, Theodore Ts'o ty...@mit.edu wrote:
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/
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
