STEED - Usable end-to-end encryption

[Tom Ritter]

On 18 October 2011 12:00, Werner Koch <wk at gnupg.org> wrote:
> On Tue, 18 Oct 2011 16:35, jerome at jeromebaum.com said:
>
>> operations will be the most important part to making that work, and the
>> ISPs don't have to help out there (modulo webmail which isn't even
>> end-point).
>
> Even webmail.  It is easy to write a browser extension to do the crypto
> stuff.  Installing browser extensions is even easier than installing
> most other software.


It's not easy.  I'm aware of FireGPG, CR-GPG, and Penango and they
range from non-functional to barely-functional, some of the time.

Email encryption is a super-hard problem because even within a 'target
audience', you have to deal with hard problems, and
cross-target-audience they get even harder.

The Young Crowd: Most people I know use gmail web interface and their phone.
The Old Crowd: Most of these folks I know use yahoo, hotmail, or their
ISP with Outlook Express.
The Super-Old-Crowd: Anything, but it needs to be easy enough to set
up that a member of the Old Crowd can do it *for* a member of this
crowd.
Corporate: It has to enterprise manageable, key escrow, compliant, etc
Devs/Security Folks: Key Management! My private key can never leave my
possession.
Other Security Folks: Absolutely NO javascript cryptography.  Zero, none.

And there's the very practical problem of _sometimes_ I do need to
read my mail from a machine that is not my own.  As a security person
I almost never do it.  But 'the young crowd' do it all the time.  You
have to satisfy that requirement also.

>From what I've seen - S/MIME within an organization satisfies most of
Corporate, until you send an email outside the organization.  Enigmail
satisfies some developers/security folk (but you lose email on your
phone and webmail - which is pretty nice.)

Any solution you come up with for one group _should_ interoperate with
the solution(s) for the others.

And any solution that relies on an ISP or webmail provider making
changes is just unlikely.  The most innovation we've seen recently has
come from the Chrome and Mozilla teams who are driving browser
security with HSTS, Pinning, and Content Security Policy.  Internet
Explorer is driving browser security in another direction with
reputational-based downloads and anti-phishing.

So trying to drive a secure, browser-based cryptoapi seems to be a
reasonable possibility.  (See DOMCrypt).  For browsers without the
API, you could use a plugin to provide it, and eventually hopefully
the browser makes it part of the browser proper and the extension is
obsolete.
That almost solves webmail.  Except that the provider needs to support
it - and you could opt to leave your key on the server vs not, that
partially solves key management (because it's a choice).  It could use
OpenPGP and interoperate with Enigmail/Mutt.  But you're still left
trying to interoperate with corporate, phone-mail, convincing
yahoo/hotmail/other obscure webmails to support it, intergrating it
into the next Outlook Express ("Windows Mail" I think?), and having an
understandable UI.

I've been working with and on remailers recently, and this is a
similar problem.  It's bloody hard.  I don't know if there will ever
be a better solution than what we have now, and what we have now
sucks.

-tom