
The Dream of Usable Email Encryption Is Still a Work in Progress - Jerry2
https://motherboard.vice.com/read/google-yahoo-end-to-end-email-encryption-work-in-progress
======
nickik
I think keybase has the best attempt at a solution. They solve two fundamental
problems.

1\. Identity. its the sum of your online presence.

2\. Insecure devices. In keybase devices have unique keys and can can be
revoked when lost

I have been trying Protonmail, they have been deploying gpg in browser and
apps. The interface is nice and I would have no problem recommending it to my
parents. The problem is that it currently only works with other Protonmail
users. Once they allow adding public keys for contacts and searching
keyservers/keybase it will be quite nice and useful.

They have no solution for the key security on the mobile phone. I personally
dont want my key on my phone.

I would really like to see a product that interfaces keybase and protonmail.
Nicely designed apps and webinterface that all have different keys. Directly
integrated with my social media contacts.

Thanks to everybody working these problems.

~~~
cm2187
Your mobile should be one of the safest places to store a key. Think of the
work it takes the FBI to open an iphone. You have a closed, encrypted device
which runs app whitelisting. Nothing is perfect but compared to a desktop
computer it is a safe vs a shoe box.

You just need to keep a copy offline in case the device is stolen.

~~~
tombrossman
> _" Your mobile should be one of the safest places to store a key."_

I have to take issue with this. I think your mobile is probably one of the
least secure places to store a key, due to the 'baseband problem'[0]. Your
mobile in its normal (powered-on and connected to a network) state is probably
less secure than using a fresh un-patched install of Windows XP today. I mean
the original version of XP, pre-SP1 with the firewall disabled.

This is why people say to choose a device without a mobile radio chip at all
for secure communication, such as an iPod Touch[1].

I'd really like to have PGP/GPG encrypted emails on my mobile and I had it
tested and working for a little while before looking into the baseband issue.
I've since revoked the keys I used for that test and I am resigned to the fact
that I will not be able to securely use encrypted email on my mobile phone for
the foreseeable future.

I keep my keys off the phone now, along with an unpublished email address at a
different domain which is to be used for account recovery for those email
accounts in use on the phone.

[0][http://mobile.osnews.com/story.php/27416/The_second_operatin...](http://mobile.osnews.com/story.php/27416/The_second_operating_system_hiding_in_every_mobile_phone)

[1][https://twitter.com/csoghoian/status/686035633949818881](https://twitter.com/csoghoian/status/686035633949818881)

~~~
tptacek
The iPhone baseband processor speaks a point-to-point USB-like protocol to the
AP, and does not have access to secrets stored in the AP or the secure
enclave. Secure applications on the phone have to assume that the cellular
network is insecure already, so the colocated baseband processor doesn't much
impact the threat model.

So, no, this is not a good argument.

~~~
tombrossman
Not a good argument for the tiny fraction of smartphone users who happen to
use iPhones, or not a good argument at all?

The comment I replied to mentions the iPhone, but made the blanket statement
_" Your mobile..."_ plus the article I linked to addresses multiple mobile
OSs.

It would be helpful to explicitly state which make and model smartphones you
believe are not susceptible to baseband threats. I think Blackphone has also
integrated countermeasures but information on this topic is pretty sparse.

~~~
tptacek
Modern iPhones are generally _significantly_ more secure than modern Android
phones, but so long as we're talking about (a) modern mobile devices (b)
provided by Apple or Google, then I'm comfortable saying that all these
devices are more secure than your computer --- which, for what it's worth, is
littered with all sorts of little embedded doohickeys with code you can't see.

~~~
tombrossman
Okay good to know. Not sure who's downvoting you because this is useful info.

Now if we can forget the comparison between smartphones and computers, it
would be great to know exactly which smartphones are a good choice for users
of encrypted email. I'm on Android now only because it easy enough to root and
use without any Google services (I prefer to self-host and use F-Droid for
apps). I don't particularly like Android but it is the 'lesser of two evils'
for now.

If I can do the same with an iPhone and never have an account with Apple I
would definitely be interested as the iPhone hardware seems pretty good.

------
tptacek
Another reasonable way to look at this situation is to conclude that trying to
provide safely encrypted email is _not a good idea_. The protocol is, in this
argument, simply too hostile to sound cryptography to reliably encrypt things.
Instead, we should focus on:

* Getting providers to safely engage TLS for MTA-MTA mail relaying, for instance by deploying key pinning.

* Making existing non-seamless cryptography (PGP) functional enough that it can be used in exceptional cases.

* Deploying new asynchronous encrypted messaging systems --- things like what Adam Langley was shooting for with Pond --- that were designed from the start with security in mind.

Secure-by-default email would be nice to have, but it's not the only option.
We could, instead, deprecate SMTP email.

~~~
atmosx
> Making existing non-seamless cryptography (PGP) functional enough that it
> can be used in exceptional cases.

Hm, I don't believe it's a technical problem, although it's a recurrent theme
among techies. PGP is hard to explain to someone who didn't spend the time to
digest certain concepts but installing GPGTools on your mac, generating a key
and using it is not hard, nor complicated... You can even store the passphrase
in the keychain.

I believe that most people using email don't feel there's any added value in
using GPG, that's all. This might change in the future, but we're not there
yet.

------
noobie
I use Keybase + Thunderbird + Enigmail. It's not the most user-friendly
approach but honestly I think whoever is not willing to go the distance now
doesn't really value encryption/their privacy and thus won't quite care when
encryption is more usable/ mainstream.

~~~
adrianN
I agree with you, but I think that we should try to make encryption something
that you don't have to "do". HTTPS is widely used even by people who don't
really care about their privacy, because it just happens automatically. I'm
not sure whether it will ever be possible to do the same with e-mail, but I
think it would be cool if all messages where encrypted and authenticated by
default.

~~~
Freak_NL
The challenge here with authenticated end-to-end encryption, is that it
depends on having the user's private key available. Whereas for HTTPS no
secret knowledge factor belonging to the user is needed (unless you use
client-side certificates). That simplifies matters quite a bit.

~~~
XorNot
Trust would be a better problem to solve then encryption, at least initially.
The big problem plenty of people have with email (and for me at least, the
phone) is establishing who I'm actually talking to when dealing with a
business.

It would be really great if when my bank emailed me, the message was signed
with the key they use on their website so we could seamlessly establish that
it was really from them.

~~~
Freak_NL
Unfortunately, banks (at least in The Netherlands) seem to favour a different
solution altogether, which is not to send e-mails at all, but expect you to
log on frequently on their on-line banking environment to look in your banking
'inbox' there.

Banks, insurance companies, pension funds, the revenue service, the local
municipal government; they all expect you to frequently log on to their
portals, and look at their digital correspondence addressed to you there. Some
do send a notification e-mail stating that 'a message is waiting for you', but
you never know if that message is actually important or merely trivial noise.
They have declared e-mail dead.

I abhor this situation, because with e-mail (and coincidentally, old-fashioned
paper mail) all correspondence addressed to me comes to me in a single inbox,
where I can archive and backup important stuff. I really wish I had the option
to simply upload my GPG public key to these portals so that all these phony
inboxes simply mailed me my correspondence encrypted!

------
vmateixeira
Is there something that I'm missing here? Google and Yahoo are developing an
encryption mechanism which will prevent themselves from reading users emails?
I thought that was part of their business..

~~~
rubyfan
It's not just Google and Yahoo, it's the other email providers, i.e. Your
employer.

It's pretty common for corporations to use their own root certificate so they
can snoop your HTTPS, one would have to assume security officers wouldn't be
really interested in individual employees encrypting their mail at the MUA and
the company losing visibility on outbound messages.

The thing I never got though, is why signing messages never really caught on.
You'd think banks and financial service providers would have an interest here.
Maybe they don't want to deal with the support headache.

~~~
tptacek
Employers that care about this will simply ban origination of E2E secure
messages from their networks. Plenty of large companies already ban web mail
providers entirely, for similar reasons. So this isn't much of a factor in
adoption of encrypted mail.

~~~
rubyfan
Right but my point is, big corporations are actively opposed to E2E secure
messages and that's a barrier to adoption.

Few if any big companies are going to be sending you GPG/PGP encrypted or
signed email or be willfully receiving it. Take the Fortune 1000 off the list
of potential secure email users and you've got a large portion of the
professional class who won't know how to use this technology. I think that's a
barrier to adoption.

~~~
tptacek
Big _employers_ don't care; web mail is already problematic for them, and E2E
doesn't significantly change things.

~~~
rubyfan
Different issues entirely.

------
Bino
E2E encryption has a very long way to go. If PGP or S/MIME were the answer it
would had successes (conquered the world) by now. I do appreciate the security
advocates preaching PGP, but in all fairness it may be a lost cause. Some
security is better than none and so we should applaud google and others'
initiative to improve the encryption at the transport (SMTP protocol) level,
without too much involvement of the end-user. And hope more will follow,
whatever it may be.

[https://gmail.googleblog.com/2016/02/making-email-safer-
for-...](https://gmail.googleblog.com/2016/02/making-email-safer-for-you-
posted-by.html) [https://openbit.eu/projekte/trusted-internet-
services/](https://openbit.eu/projekte/trusted-internet-services/)

~~~
tptacek
Because of the way technology adoption works, pushing for "some security" over
"no security" is a good way to end up with "some security" (and, because
attacks only get better, over the long run back to _no security_ ) forever.

------
drakenot
I've been eagerly awaiting the release of this e2e plugin. However, I'm not
holding my breath. Go take a look at GitHub repo[0]. The last commit was a
merged pull request on Feb 24th and the commit before that was Jan 27th.

[0] [https://github.com/google/end-to-
end/commits/master](https://github.com/google/end-to-end/commits/master)

------
dave2000
Surely the idea that all email providers/clients/services will all suddenly
work together and solve the ui and technical problems inherent in PGP use is a
bit of a dream, and in fact the answer is to just not attempt it and instead
use encrypted im sessions which already exist.

------
beardog
Its not email, but a "similar" protocol (similar in the way the user interacts
with it) that is secure is
Bitmessage([https://bitmessage.org/](https://bitmessage.org/))

------
vu3rdd
There is this nice guide:
[https://emailselfdefense.fsf.org/en/](https://emailselfdefense.fsf.org/en/)

It has instructions for all major operating systems.

~~~
nhf
This guide is nice for people that are motivated, but a large chunk of users
(probably the majority, but I have nothing to back that up except a guess)
will only encrypt their emails when it's as frictionless as sending an
unencrypted email.

Encryption tends to be successful when it's baked in to the system (e.g.,
WhatsApp theoretically), a preset default (e.g., Android 5.x+ and iOS), or
requires absolutely minimal effort (e.g., the HTTP -> HTTPS "switchover").
This has been a known issue for a pretty long time [1, 2].

[1]
[http://www.gaudior.net/alma/johnny.pdf](http://www.gaudior.net/alma/johnny.pdf)

[2] [https://cups.cs.cmu.edu/soups/2006/posters/sheng-
poster_abst...](https://cups.cs.cmu.edu/soups/2006/posters/sheng-
poster_abstract.pdf)

~~~
dublinben
Once you've set up Enigmail with your PGP key, it _is_ as frictionless as
sending unencrypted mail.

I use Enigmail to send encrypted email on a daily basis. It couldn't be much
easier than it is already.

------
yyin
I'd prefer to see decentralized email before "encrypted" email.

Recipient runs qmail listening for connections on some personally chosen port
from among 1000's of choices. She is also running a firewall such as pf.
authpf might also be useful.

Recipient tells sender her chosen port number and a personally chosen address
to use. How does she do this? In person. Through the postal mail. Over the
telephone. But _not_ over the Internet. Of course she does not have to use the
same port and address for every sender.

In addition to the potential randomness of the port, the address she chooses
could be any string of legal characters up to 250 whatever in length.

The approved sender runs qmail to connect to recpient's qmail and leaves a
message on recpient's computer.

No DNS. No "email provider". No POP3.

How two users can discover each others' IP address and connect to each other
through firewalls _without forwarding traffic through a third party server_ is
left an as exercise for the reader. Chances are most users have used software
that does this at one time or another, maybe without even knowing it. The
methods have been around for decades. It works.

Centralized DNS and the need for a "domain name" is not needed.

Centralized "email providers" who store users' email are not needed.

There are a number of disadvantages and limitations to this approach. Yes, I
know what they are. But I have already tested this and it works so I'm biased.

My opinion is that the _advantanges_ of "peer-to-peer", SMTP-to-SMTP email
easily outweigh the disadvantages of store and forward and POP3 and make this
a useful _alternative_ (not a replacement) system for centralized email. It's
an _option_ users could have that would be quite useful.

The status quo approach to email has become highly centralized in both the
need for ICANN DNS and "email providers". Not to mention the commercialization
of email and the need to have "permission" to be able to send mail "because
of" the proliferation of spam. It's far too difficult for any user to control
their own email under the current centralized system. Solution: Give users
another system where they _can_ control their email.

IMHO the centralization and protectionism of the current system (email is a
business, but it doesn't need to be) is a bigger problem than lack of
encryption. It's also what makes spamming viable. Everyone knows your email
address or can get it easily enough. In many cases, that is not necessary.

As it stands, email is concentrated in a limited number of locations (the
servers of email providers), transferred over a few ports (25, etc.) and users
are limited in the addresses they can use (commercially registered
domainnames).

~~~
tracker1
It's just the nature of decentralized + secure + anonymous (at least to the
transport layer) ... you can't realistically have all three without being open
to effectively a DDOS, poisoning the system as a whole.

I'd worked on a proof of concept that would have all three of the above
features using a DHT for delivery, relying on collisions for addressing, so
that targets overlap, but a given target could only decrypt messages actually
to them... the down side is it would be possible to send _MANY_ messages to a
target, so many that the system would be brought to a crawl and effectively
useless.

