
An Update to End-To-End - aarkay
http://googleonlinesecurity.blogspot.com/2014/12/an-update-to-end-to-end.html
======
mrsteveman1
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...](https://github.com/google/end-to-end/wiki/Threat-
model#backdoor-in-end-to-end-source-code)

------
jMyles
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?

~~~
lallysingh
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.

~~~
avz
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.

~~~
comex
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.

~~~
Animats
_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.

~~~
comex
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.

~~~
jesrui
> 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.

------
jmnicolas
> _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.

~~~
nullspace
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.

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

~~~
icehawk219
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/](https://developer.github.com/v3/issues/)

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

------
driverdan
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.

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

------
sft
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.

~~~
notatoad
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.

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

~~~
notatoad
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.

------
higherpurpose
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.

~~~
lallysingh
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.

~~~
higherpurpose
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?!).

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

~~~
mjevans
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.

~~~
Tomte
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.

