Google Open Sources Encrypted Email Extension For Chrome (onthewire.io)

Last week Google released E2EMail, "a Gmail client that exchanges OpenPGP mail." Google's documentation promises that "Any email sent from the app is also automatically signed and encrypted... The target is a simple user experience -- install app, approve permissions, start reading or send sending messages." Trailrunner7 quotes On The Wire: People have been trying to find a replacement for PGP almost since the day it was released, and with limited success. Encrypted email is still difficult to use and painful to implement in most cases, but Google has just released a Chrome plugin designed to address those problems. The new E2EMail extension doesn't turn a user's Gmail inbox into an encrypted mail client. Rather, it is a replacement that gives users a separate inbox for encrypted messages. The system is built on Google's end-to-end encryption library, and the company has released E2EMail as an open-source project.
Wired quotes a web security researcher who calls the open sourcing "a telltale sign the project isn't going anywhere. This is a way for them to get their work out there but to absolve themselves of future obligations." But Google's privacy and security product manager responds that they're tackling some very thorny issues like secure key handling, and "The reason we want to put this into the open source community is precisely because everyone cares about this so much. We don't want everyone waiting for Google to get something done."

Comments

Let me count the problems...

[Entrope]

Having a plugin is nice, but it doesn't solve the PKI (key distribution and reputation) problem, and I am not very inclined to trust a plugin made by a company whose primary line of business is advertising by building user profiles.

Re:Let me count the problems...

[Anonymous Coward]

Having a plugin is nice, but it doesn't solve the PKI (key distribution and reputation) problem,

RTFA. They've provided a keyserver based on OAuth and a "trust on first use / warn on change" local cache. It solves the problem better than traditional PGP, albeit with less (nonfunctional) kool aid.

and I am not very inclined to trust a plugin made by a company whose primary line of business is advertising by building user profiles.

Then read the source, or expect others to do so and destroy Google's reputation if there are backdoors. The alternatives to the plugin are written by anyone who can send a pull request, ie. NSA. The fact that Google has some reputation to lose puts the situation above average, same as with Chrome. Either way, trust in the adversarial scenario depends on someone auditing the source and on long-term author reputations.

Re: Let me count the problems...

[Entrope]

Adam wants to send a message to Betty without anyone being able to snoop on it. Eve wants to snoop, for example by tricking Adam into thinking Eve's key belongs to Betty, or keeping Betty from reporting that get key changed due to a compromise. PKI is how you keep Eve from being able to fool with keys.

SMIME and DANE ?

[johnjones]

How about support for SMIME ?

It would be nice if they supported DANE so that all the keys where looked up automatically!

Why not ?

John

Re: SMIME and DANE ?

[corychristison]

I long for the day that we can universally use DANE with SSL/TLS Certificates, and cut out the Certificate Authorities.

Greetings from the alternate universe!

[TheRealHocusLocus]

People have been trying to find a replacement for PGP almost since the day it was released

I've been around since PGP first popularized public key email and while there have been various problems with Zimmerman's implementation from time to time (as with S/MIME since)... I do not recall any broad opposition to it or GnuPG... besides intelligence agencies who would be satisfied with nothing less than outlawing non-escrow encryption. We were in fact excited and intrigued by it, and it was fun to use even if you weren't paranoid. This must be a dispatch from the Millennial Alternate Universe where or any project emitted by Microsoft or promised by Google or announced in a press release is considered to be a vast improvement on what came before it.

End-To-End Encryption implemented solely in Javascript which is served up by the company that's not supposed to be spying on you is not worth the paper it's printed on. And Key Transparency is a fancy way of saying, use our single point of failure Internet Gizmo 'solution' to handle key management so you don't have to think about insurmountable issues of trust, as were directly addressed in Zimmerman's day (key signing parties, etc.).

Re:Greetings from the alternate universe!

[grumpy_old_grandpa]

When Snowden wanted to initiate communication with Greenwald, would it really have been a good idea to use keys which were linked to their real names? And either way, using existing keys or newly minted ones, wouldn't they have to confirm the key fingerprints off-channel anyway? In that scenario, you really want to make sure you got the right one.

For other types of communication, the threat model is different: When I send a message to my family, the content of the message is probably enough to establish that it was genuine. It would still have been nice if all governments and spies along its route would have a harder time reading it, though.

The scenario I could see signed keys being helpful in, is valuable communication between two strangers. E.g. if the two us wanted to make a trade, and you'd send me your Bitcoin address, I'd trust you more if the message was signed with a signed key. However, if you were selling me illegal goods, we're back to square one. Neither of us would communicate with real names.