Making end-to-end encryption easier to use (Google Online Security Blog) [LWN.net]

The Google Online Security Blog has announced the alpha release of an OpenPGP-compliant end-to-end encryption extension for the Chrome/Chromium browser. "While end-to-end encryption tools like PGP and GnuPG have been around for a long time, they require a great deal of technical know-how and manual effort to use. To help make this kind of encryption a bit easier, we’re releasing code for a new Chrome extension that uses OpenPGP, an open standard supported by many existing encryption tools. However, you won’t find the End-to-End extension in the Chrome Web Store quite yet; we’re just sharing the code today so that the community can test and evaluate it, helping us make sure that it’s as secure as it needs to be before people start relying on it. (And we mean it: our Vulnerability Reward Program offers financial awards for finding security bugs in Google code, including End-to-End.)"

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 14:16 UTC (Wed) by riccieri (guest, #94794) [Link] (15 responses)

Interesting to see Google investing in end-to-end encryption, given that it goes directly against their revenue model on Gmail.

Maybe they consider the PR benefits higher than the potential loss of ad revenue?

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 16:08 UTC (Wed) by njwhite (guest, #51848) [Link] (14 responses)

It is interesting. It sounds like they're betting on people only using it for odd messages, rather than the majority: "We recognize that this sort of encryption will probably only be used for very sensitive messages or by those who need added protection".

If they were serious about useable security they'd try to push it to do the work to become the default sending & receiving method when it knows the recipient can do OpenPGP too. I suspect they won't take this step. Let's hope they prove me wrong.

Though of course their system stores the private key in the browser, that is proprietary and auto-updates according to the demands of a US based company, so this isn't quite the normal "only you and the recipient know the contents" situation, in the default setup (a distribution provided chromium and not "chrome web store" extension installation is a different story).

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 18:08 UTC (Wed) by alison (subscriber, #63752) [Link] (13 responses)

For Gpg encryption linked to usual keyservers, check out Mailvelope for desktop and K9-mail for Android. Mailvelope is even AGPL'ed.

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 19:49 UTC (Wed) by riccieri (guest, #94794) [Link] (10 responses)

Mailpile (https://www.mailpile.is/) is also interesting: A gmail-inspired (local, but browser-based) e-mail client. It has a strong focus on security, with built-in OpenPGP support

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 21:43 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (9 responses)

Does it implement its own PGP or one of the PGP Intents providers (e.g., APG or OpenKeychain)? I'd much perfer the latter since then only one app actually has access to my private key (and access to it is an application switch which should be obvious).

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 23:40 UTC (Wed) by riccieri (guest, #94794) [Link] (8 responses)

> Does it implement its own PGP or one of the PGP Intents providers

AFAIK it just shells out to GPG. Also, it is a web app (made to be run locally), not an android app. I don't think they're targeting android, but I guess it could run there too (and be accessed through the normal browser).

As for the integration, I guess it should be possible (and would be pretty cool).

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 23:44 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (7 responses)

Heh, so now we've started making "desktop" apps launched through the browser too? That History of JavaScript talk is becoming more and more true…

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 4, 2014 23:55 UTC (Wed) by riccieri (guest, #94794) [Link]

> Heh, so now we've started making "desktop" apps launched through the browser too?

That's pretty much it :)

I'm unaware of statement by the team of why they made this decision, but I can try to guess: easier to find developers to work on it, user familiarity (given that they're targeting a Gmail-like interface), cheap cross-platform support (their backend is python)...

Personally, I would like if they eventually build multi-account support on it, like Horde or SquirrelMail. It would make a great alternative for small businesses that like the Gmail interface but don't want Google looking at their stuff (or find Google Apps too pricey).

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 5, 2014 6:18 UTC (Thu) by Lennie (subscriber, #49641) [Link] (5 responses)

There used to be three problems why people use extensions for this and the first two are already solved.

The first problem is the crypto itself which is possible to do in Javascript these days because a W3C standard WebCrypto API exists. So for example the browser has an API to a cryptographically secure PRNG.

Google version does the crypto in Javascript. So there is no dependency on having PGP installed or needing access to local executables.

The second problem is storage. If you have private keys for encrypting signing your emails you send with gmail. Would you want to storage those in gmail ? Euh, no. Obviously not. There are solutions for that. Store at a third party: https://unhosted.org/ http://remotestorage.io/ and encrypt before you store: https://github.com/diafygi/byoFS

The third problem with Javascript is, the files aren't signed. That is why people are still using extensions which makes it sort of part of the browser instead of the page which was downloaded from a potentially untrusted source. Which should make it more secure.

The closest thing I know of that does something like that would be this IETF draft which adds signature is:
http://tools.ietf.org/html/draft-cavage-http-signatures-00

But that is just a partial solution.

That is why I think http://css.csail.mit.edu/mylar/ is interresting.

What they do is, they have a general extension that check if the files are signed. But the extension is very generic so it should be possible to make a W3C standard of it and include it in every browser.

I always wondered why the W3C has never created a standard for signing files before.

I could be wrong, but I think the Netscape browser even had support for signed Jar files, which could include Javascript instead of Java. And the Netscape browser is already dead for a long time now.

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 5, 2014 6:48 UTC (Thu) by Lennie (subscriber, #49641) [Link]

I forgot to mention compartmentalization. Browsers have an API to offload to other 'processes'. The only method of communication is through a messaging API. It's called Webworkers and Sharedworkers.

Obviously, Chrome already uses different processes to do keep code in different parts of memory and the developers of this extension know how Chrome handles this. Thus they can know if it is done in a secure way.

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 6, 2014 7:27 UTC (Fri) by ncm (guest, #165) [Link] (3 responses)

When the spooks deliver a "national security letter" to Google demanding a back door, would Google, then, not sign that release? This is end-to-end only in a marketing sense, i.e. not at all. Nobody has any sound reason to believe the JavaScript delivered offers any real security.

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 6, 2014 7:54 UTC (Fri) by Lennie (subscriber, #49641) [Link] (2 responses)

Ahh, but the next step is to have it signed in such a way that we can see what the git revision is that the files were part of.

Then in the case of an open source project, then people can see if things changed/what changed.

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 6, 2014 12:57 UTC (Fri) by njwhite (guest, #51848) [Link] (1 responses)

It's not a problem unique to the Chrome way of doing things, but what if the NSL said "don't offer security updates of this extension to this user." No malicious code need ever be written or distributed, let alone make it into a git repository, but the end result could be the same. There was a good talk about difficulties like that at Libreplanet 2014 by Seth Schoen. It's a tough problem, to say the least.

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 7, 2014 11:53 UTC (Sat) by Lennie (subscriber, #49641) [Link]

If anyone wants to see the talk by Seth Schoen, I found some partial recordings:

"What does this program do? Reproducible builds, transparency, and freedom"

http://b.mtjm.eu/libreplanet-2014.html

Did you notice he said it a naming problem ?

Software distribution over the Internet isn't really secured properly.

There is no way to know if you are running an old version or the latest version or some version specifically created to attack a few people.

Now look at the Internet as a whole.

Only protocols like email and the web are properly federated, although a large number of people are using a few large players (like the gmail case).

HTTPS is secured by the Certificate Authorities, but that isn't perfect. To say the least.

Now watch this talk by Dan Kaminsky and assume DNS is secured. He talks about bootstrapping trust:

https://www.youtube.com/watch?v=kXvZZ-t_WYA

There is a whole set of protocols around DNSSEC, like DANE to secure certificates for HTTPS, SMTP, POP, IMAP, maybe XMPP, etc. And also for SSH.

You can also solve that software updates problem. All you do is publish a hash in Secure DNS.

Now we get to the next problem.

DNS is used to bootstrap everything, but it isn't always secure. Even when it is secure, it is not trusted by everyone. The DNSSEC root keys are in the US, controlled by US companies and an US institution.

So we need a different way to bootstrap DNS(SEC) trust.

My suggestion is something like Namecoin.

So this can actually be solved.

And we actually have smart people that know what needs to be done.

But who is gonna do it ?

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 5, 2014 7:22 UTC (Thu) by MKesper (subscriber, #38539) [Link] (1 responses)

If K-9 only would add PGP/MIME it would be usable...

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 5, 2014 11:58 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

One of the developers recently made a fork[1] to work on it. There are also other K-9 forks which supposedly support it (Squeak and one other I forget).

[1]https://github.com/k9mail/k9mail_pgp_mime

Making end-to-end encryption easier to use (Google Online Security Blog)

Posted Jun 12, 2014 10:11 UTC (Thu) by anguslees (subscriber, #7131) [Link]

Huh, I held romantic notions of adding pkcs-11 browser bindings one day (with a software token outside the sandbox and a pass thru to hardware).
Good to see something like this becoming available - I hope it's generic enough to be used for more than just pgp.