An Update to End-To-End | Hacker News Reader

An Update to End-To-End

googleonlinesecurity.blogspot.com

142 pointsaarkay38 comments

Given that they've already decided to include support in Chrome itself for accessing USB hardware security tokens for U2F, I see no reason why they couldn't do the same with End to End + OpenPGPCards like the Yubikey NEO, which happens to also be a U2F device.

It would provide a solution to some of the issues they document on their own Wiki regarding secret keys being stolen by an attacker through another Chrome extension, another application on the system, etc.

EDIT: YES! I missed this part[1] in the Wiki earlier:

"Additionally, we plan to add remote private key support in the future. When support for that is ready, high-risk users could protect their secret keys (stored, e.g., in a hardware USB device) from compromise even when an adversary introduces a backdoor in the source code."

[1] https://github.com/google/end-to-end/wiki/Threat-model#backd...

I mean, this seems just straight amazing, right? Am I missing something?

Obviously Google is pivoting on a number of fronts; if this enjoys wide adoption (unlikely as that may seem at the moment), they'll have to basically retreat from email content analytics, right?

Perhaps the additional user trust is worth it?

But the other cost is searchability, which is a pain for a search-based email system. I don't think many people use labels very much.

Considerable value of the search functionality can be retained by restricting it to metadata like originator which needs to be accessible for delivery to work anyway.

I completely agree. I'm curious on what's lost on the tail, however. Then again, I don't find many things that way, anyways.

For me at least, this would be completely unacceptable as a search replacement, as I frequently search old message bodies. Not to mention that there's no reason originator can't be encrypted at rest, at least in theory..

However, based on the experience of desktop search, I think pure client side search would probably have reasonable initialization time and space overhead, and would certainly make searches faster, at least compared to my current Gmail experience.

For me at least, this would be completely unacceptable as a search replacement, as I frequently search old message bodies. ... However, based on the experience of desktop search, I think pure client side search would probably have reasonable initialization time and space overhead, and would certainly make searches faster, at least compared to my current Gmail experience.

Just install Mozilla Thunderbird and use IMAP. Client side search, all your devices sync via IMAP, no ads, and free software.

FWIW, I've evaluated email clients from time to time, but haven't found anything I like enough to replace Gmail. I haven't tried Thunderbird for years because I don't want to use a client without conversation view, and Thunderbird doesn't seem to offer it as a core feature; I could try one of the extensions for it, but I'm suspicious it won't work well. Also, I'm not sure I want to start using a product that's been on life support for two years. However, I admit these are relatively small turnoffs, so perhaps I should give Thunderbird a spin some time...

Anyway, it's off topic.

> I don't want to use a client without conversation view, and Thunderbird doesn't seem to offer it as a core feature

Actually it does, sort of: Right click on you@example.com, choose Search Messages, then Save as Search Folder, then "Match all Messages" and, in "Select the folders to search", Inbox and Sent.

Probably.

They make most of their money on Google search anyway - and with just the queries, no personal context as far as I know. No privacy issues arise here, in fact, it would probably work in incognito mode just as well.

Are there any numbers on how much profit they actually make on Google Mail?

Not just searchability, auto-categorization, and anti-spam as well. I would view it through the lens of putting the power of choice in the hands of the user.

It allows people to make the choice of whether they value privacy more than usability, or, it allows fine-grained control -- end-to-end for messages you care to keep private, but no encryption for the mails you don't care about, but want searchability (mailing lists, notification emails, package tracking, etc)

Indeed. I hadn't thought of spammers looking up your public key somewhere and sending you an encrypted email with it.

You could always use white-listing for encrypted e-mails - refuse all encrypted e-mail not from people on your contacts list or people whose keys you've signed, etc.

The emails that it is useful to do analytics on and the emails that it is useful to encrypt aren't the same emails. The valuable emails to analyze for a company who sells targeted advertising are the transactional emails - booking confirmations, purchase receipts, etc so they can build up a profile of what your habits are, and it is incredibly unlikely that anybody is going to start encrypting those. The email you send your boss updating him on the latest project status, or a personal email to your parents don't have a lot of marketing value.

> booking confirmations, purchase receipts, etc

But these are _exactly_ the things I, the user, want encrypted. I would probably even stop doing business with vendors that did not encrypt their transactional communications with me.

Perhaps those of us that prefer encrypted email should begin lobbying companies to encrypt transactional emails.

I felt the same as you, until I read that Google is going to manage your keys or handle the cert. authority part (however that ends up). Then I realized their end game, which is to control end to end encryption adoption to keep another vendor from controlling it.

It's the same strategy google did with the browser and mobile. They don't want to be locked out of this play, because if they don't have influence then they may potentially loose all sorts of profiling data on you. So, with Google controlling the adoption they can ensure mechanisms to provide services around your encrypted data to benefit you (while also serving google by letting them into your encrypted life).

Unless I'm reading this wrong, according to the End-to-End docs, it looks like keys are kept in a "Key Directory", and that Google will run one Key Directory, but you can use whatever Key Directory you want. I haven't seen evidence that Google will have any access to your unencrypted data.

You don't need to analyze content on the Gmail server to get content analysis to the Gmail server (if that is necessary at all).

If Google's primary intent is to make sure that users keep their email encrypted completely, smart clients (like browsers and mobile apps) can do what Gmail servers can't.

Look at what the Google-provided Gmail Offline extension does. Now remember that End-to-End is just an extension, like Gmail Offline, except that this one also decrypts email on the client. Once email is decrypted on the client, analysis can be performed (like indexing the email for search), and that analysis can be sent to the Gmail servers or used to perform ad calls directly (I'm not saying that Google is doing this, but technologically all of this is pretty easy given everything else already done).

My bet: End-to-End encryption, not even automatic but through the use of a plugin, will only appeal to the niche of people who are concerned about that and may not be using GMail. For the most part of its user base, nothing will change.

Things will start to move for the majority when end-to-end encryption can be done directly in the protocol, by default, i.e anything but email.

> We’re migrating End-To-End to GitHub

A bit off-topic but it seems to me that Github is fast becoming a "too big to fail" actor.

The switching costs away from Github is trivially low actually. You may lose out on some of the niceness related to github - but there are plenty of good git based source code hosting software out there.

The only pain point in switching I can think of is issues/wiki. Are they exportable from GitHub and importable into something like BitBucket?

The wiki is just a Git repository so you could just clone that and then do what you need to with it. Once it's cloned locally I'd imagine it's fairly straight forward to either manually copy it to something else or use an API to copy the files up to a wiki somewhere.

For issues GitHub has great API coverage for fetching them [0] so I'd imagine it's not terribly difficult to write a migration script. There are already ones out there for going from BitBucket to GitHub [1] so the reverse should be possible.

[0] https://developer.github.com/v3/issues/

[1] https://github.com/vbabiy/bitbucket_issue_migration

I should have been more clear about what I meant : I was thinking of failing as in downtime not the company being bankrupt.

Imagine a cyber-attack that would paralyze Github for one month ...

Can anyone who has been using End to End provide some feedback and additional info about it? The docs (and blog posts) don't really say much other than it encrypts text.

How could a regular user start using this (unless it is not ready at all for the "fearless ones")?

I wish they would stop calling it End-to-End, it's misleading, they don't talk about DNS at all. One weak link in the chain means the entire chain is weak.

DNS is not relevant at all here. Your email is encrypted client-side at one end, and decrypted client-side at the other end. At no point in between does it exist in cleartext. If there is some DNS vulnerability that causes your email to get intercepted, that in no way compromises the encryption.

Here? Where is here? The blog mentions nothing about email specifically.

Whatever. "here" is any text encrypted by this module, whether it is the body of an email or something else. The data isn't getting decrypted mid-stream, it goes from one client (or "end") to another. It is end to end encryption, and DNS has nothing to do with it.

I hope they don't work too hard to making it compatible with PGP (and probably shouldn't at all). Just through Gmail and Yahoo alone adopting it, the end-to-end encrypted e-mail user base could increase by 100x. So it makes little sense to make it backwards compatible, especially if that creates potential security issues.

One of the benefits of PGP is that it's stood up pretty well to the test of time. Incompatible changes would be a little suspect, from a security perspective.

PGP's lack of forward secrecy seems like a major flaw, unless they can somehow make it easier to have the benefits of PFS while keeping the current design. But didn't they already say they intend to use elliptic curve keys instead of RSA for much better performance? Wouldn't that already break compatibility with PGP?

The only real downside I see from breaking PGP compatibility is that then the new system will need a few years before it can really be "trusted".

However:

1) it already won't be very trusted since it happens in the browser, and it will be quite hard for Google to absolutely guarantee without a shadow of a doubt that they can't change any settings themselves (even though they own the Chrome browser and the Chrome store, on which the extension will live).

2) being new doesn't mean it can't be better. We already have better secure messaging crypto protocols such as Axolotl, so it is possible to make one that's both new and better. (I actually wonder why we can't just use Axolotl for an email interface, and call it a day?!).

Forward secrecy on PGP? So I can't go read my old love letters?

Forward security typically means you make it possible, after the session is complete, for anyone to have said anything during the session. Thus making it possible for any potential log of said session to be forged and presented as 'evidence'; therefore implying that even a log which happens to exist on someone's computer is in fact forged (or more to the point, that any potentially recovered log or monitored log is forged; even if an identity has signed off on the session key).

So if 'PFS' was used with a sent message then anyone/everyone would be able to read or forge the message. This is not the problem that PGP/OpenPGP was designed to solve.

No, that's deniability (OTR has that property), something very different from PFS.

PFS just means you've got session keys that can't be derived from the long lived authentication key.

> PGP's lack of forward secrecy

PFS doesn't really exist in the case of emails, it makes more sense in the context of a real-time conversation.

In the context of a conversation you typically create a session that is symmetrically agreed upon by both parties and lives until one of the parties quit. This agreement includes a "session encryption key" that is completely random in the case of PFS (so it can't be used to infer other session's encryption keys, that's the point). You then use this key for the whole duration of the session (with careful re-keying at some point otherwise it's pointless)

PGP goes even beyond: there's no session, and each message is encrypted with a different key. If you had to draw a parallel, it would be as if only one party is enough to decide the parameters of a session, and all parameters would still be changing every time. Also, each session is only ever used for 1 message. If you really want to draw the parallel, then PGP is the ultimate PFS.

> I actually wonder why we can't just use Axolotl for an email interface, and call it a day?!

Because the number 1 problem in cryptography for a decentralized end-user product is not the cipher or the algorithms or do we use Elliptic Curves or whatever, it is the distribution of keys. The Axolotl ratchet is awesome, but it's only a ratchet. PGP has some stuff related to key distribution and verification, TLS has some. If we are to implement global scale email cryptography, it will more likely be on top of PGP or TLS than anything else.

Reply on news.ycombinator.com