
Encrypted email is still a pain - jstanley
http://incoherency.co.uk/blog/stories/gpg.html
======
tptacek
Encrypted email is pretty much over in 2017.

The emerging consensus among experts is that it's not worth the trouble, or,
worse, incapable of doing much more than generating a false sense of security.
That's for a bunch of reasons:

* An enormous installed base of clients that won't do encryption, meaning that at best you're attempting to tunnel encrypted messaging over an unencrypted transport.

* A protocol that leaks metadata, including some message content, at the envelope layer.

* Hundreds of millions of users that primarily access messages through browser clients that can't meaningfully implement crypto.

* An archive-always UX that ensures that huge amounts of plaintext are scattered around the Internet by both senders and receivers.

* An unencrypted installed base that ensures encryption will be opt-in for the foreseeable future, meaning that users will routinely reveal plaintext accidentally by, for instance, quoting messages and forgetting to encrypt.

* End user demands for things like search that can only be delivered efficiently at scale by databases of plaintext (most likely at centralized servers).

All these problems are probably surmountable (with enormous, concerted
effort). But: why bother? Email is just one of dozens of messaging systems
available to Internet users. Better to move sensitive conversations to things
like Signal, WhatsApp, or Wire --- the double ratchet construction is designed
specifically to make IM-like protocols secure even when conversations are
sporadic and last months.

~~~
pmlnr
> But: why bother? Email is just one of dozens of messaging systems available
> to Internet users.

No, it's not. It's the only widely available, decentralized system, with which
you can send to anyone, if you know the address. None of the big ones is this
open.

XMPP tried to address this and failed; now Matrix is trying again.

~~~
tptacek
WhatsApp has over a billion users. There are big places where its market share
exceeds that of SMS --- another big centralized service that has a userbase
comparable to that of email. My conclusion is that the people who care about
"decentralized" systems are a rounding error. I care about non-technologists
managing to send asynchronous messages to each other that are well-encrypted
by default. That's a solved problem.

~~~
pmlnr
> My conclusion is that the people who care about "decentralized" systems are
> a rounding error. I care about non-technologists managing to send
> asynchronous messages to each other that are well-encrypted by default.
> That's a solved problem.

You don't understand the problem: if you rely on a service like this, two
things can - and by the laws of probability, will - happen:

a, a centralized service goes down and suddenly no one can talk to nobody b,
you're unable to send a message to someone and never realize it

Imagine if there was _one_ ISP. One single mobile provider. If it goes down,
it goes down everywhere, for everyone. Not fun.

As for b, I can't remember, but there's a term when a provider let's you post
but it won't get show to others. They can also alter messages - see the
Whatapp signal implementation issues that certificates can be silently re-
issued.

You are, unfortunately right though: very few of us realizes how important
this is. Thankfully the smarter elders of the internet seem to do.
[https://www.decentralizedweb.net/](https://www.decentralizedweb.net/)

~~~
tptacek
No, I fully understand the problem. If Google Mail vanished tomorrow, a pretty
large number of people would probably stop emailing altogether. The number of
people for whom that's true increases every year.

If you find that unthinkable, consider the bubble you might be living in. I
appreciate that there are people that require a decentralized service for
messaging and understand where they're coming from. I don't deny their
existence. I simply think their numbers are much smaller than they appear on
nerd message boards.

~~~
problems
> No, I fully understand the problem. If Google Mail vanished tomorrow, a
> pretty large number of people would probably stop emailing altogether. The
> number of people for whom that's true increases every year.

I highly doubt that's true. Email is pretty essential to the functionality of
the internet, from signing up accounts to getting notifications, to just plain
discussions with professionals. It's pretty much the only thing that does what
it does.

To use non-nerd examples people in my life have done recently via email:
contacting the school registrar's office, updating insurance information,
discussing minor problems with a recent surgery with their doctor. Especially
for people with anxiety issues who have problems on the phone, email is a life
saver.

I lived off email when buying a house through a builder last year. Everyone
went through email and nothing else was even offered in many cases. The
builder, bankers, lawyers, electricians, everything was email.

~~~
tptacek
Three responses:

* Email remains important for middle-class Americans because it's used for business. But that is a small subset of the whole population, including very large numbers of Americans.

* For almost all those users, email might as well be a Google, Yahoo, or Microsoft product.

* Every year, the number of people and businesses that rely on email gets smaller --- in the last 5 years or so, by something like 15%.

There's no trend we're looking at that suggests that email is becoming _more_
relevant.

We should be happy about this, not freaking out. Even if you think the future
is decentralized messaging protocols (I like decentralized too; I just think
we should figure the nuts and bolts out _before_ we decentralize), email is a
boat anchor holding us back.

~~~
problems
> * Every year, the number of people and businesses that rely on email gets
> smaller --- in the last 5 years or so, by something like 15%.

If that's true then where's that stat from and how are these businesses
getting contacted online?

There's no decent replacement for email in that department at all to my
knowledge.

~~~
thenomad
Can't answer the source of the stat, but where they're getting contacted - FB
messenger or Twitter, for starters.

I've done most of my non-B2B communication with businesses over the last year
or so via FB messenger, Twitter or phone.

------
MayeulC
For what it's worth, I used to use encrypted mail some time ago as much as
possible, before realising it was fundamentally flawed:

— the key retention is the biggest issue. You need to keep your key around for
a long time, probably storing copies of it. This increases the probability of
a leak.

— there is no method to revoke a key with a 100% assurance that nobody will
use or trust it afterwards.

— if a key is broken or leaked, every encrypted message you ever received can
be deciphered. And I hope you realise it, or future messages are also at risk.

Those are the three major flaws I can remember right now. The way people
usually use it make them feel safe while they are not necessarily. It's a bit
like reusing a complex password on different websites (although far less
critical since the key is assymetric).

The way I use it now (and I never actually needed it, to be fair), is that if
some third party want to send me some confidential information, they request
my public key via an open channel, and I _then_ generate a key, unique for
this conversation (ideally, it would be done on a per-email basis). Of course,
the complex part here is ensuring they receive the proper key (ie, no man in
the middle). This can be done by using a side (preferably secure) channel.

Of course, in today's world, encrypted emails are not the best way to
communicate privately, in my opinion, but that's another story.

And there are a couple of other issues regarding encrypted emails such as its
adoption, it's complexity, etc. But none as fundamental.

~~~
drdaeman
> the key retention is the biggest issue. You need to keep your key around for
> a long time, probably storing copies of it.

As I get it, this one is a fundamental issue, not specific to messaging at
all, but is just a secure storage problem.

You either keep a copy of the message (and need some key to decrypt it, unless
you keep it unencrypted), or you throw it away. No amount of engineering can
solve this.

~~~
mjevans
That's what 'perfect forward security' is intended to solve. For more details
please look up the Off The Record (otr) protocol overlay.

The basic idea is that any given session is authenticated temporally; when a
session is completed the details for it are leaked so that anyone could forge
content as having been within that session. Thus there is reasonable doubt
about anything that was said/transferred having actually been
said/transferred.

~~~
drdaeman
No. PFS is about when messages are in transit. Sure thing, it makes sense to
encrypt them with ephemeral keys rather than a long-living ones.

However, that particular point I've quoted was - as I understood it - about
message archives. Short-lived keys are just fundamentally incompatible with
long-term storage. We either keep data, or we don't.

PFS helps for about another point raised, "if a key is broken or leaked..."
(but has a trade-off, as it requires some sort of key exchange)

~~~
AlexCoventry
> However, that particular point I've quoted was - as I understood it - about
> message archives.

In a sense you're right, but the archive in question is the one your adversary
accrued while they were intercepting your in-flight emails, which you
encrypted with your static key. Any archive you have control over is sort of
beside the point.

------
legulere
I do not get why everyone thinks that encrypted email is GPG.

S/MIME is supported by almost all email clients.

S/MIME is far less of a pain (but still some pain and could be improved).

It has a model of how to verify that keys belong to the right person, that
actually works in practice in contrast to GPG where you basically have to
verify keys by hand (adversarial CAs are a problem, but probably only for a
tiny amount of people).

~~~
lmm
a) The key management UX is even worse than GPG, at least IME.

b) If you're willing to trust the CA system the advantages of using email
rather than any transport-encrypted messenger (e.g. facebook messenger) seem
decidedly marginal

~~~
rkeene2
You control which CAs you anchor your trust to locally. Additionally, the
encryption part isn't tied to the CA system -- you encrypt directly with the
public keys of your recipients. You can use the CA system to validate that the
public key belongs to someone validated by some attributes -- certificates are
used for this.

The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use
S/MIME heavily.

~~~
lmm
> You control which CAs you anchor your trust to locally.

Theoretically, but doesn't it tend to use the same OS infrastructure as HTTPS?

> The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use
> S/MIME heavily.

Indeed, but they are in a position to trust the US government (and more
generally the international governmental system).

~~~
epistasis
>Indeed, but they are in a position to trust the US government (and more
generally the international governmental system).

Not sure what trusting the government has to do with it, it has to do with
trusting the CA system that's set up on the computer.

~~~
lmm
> Not sure what trusting the government has to do with it, it has to do with
> trusting the CA system that's set up on the computer.

Almost all computers ship with a bunch of governments set up as trust roots.
It's not impossible to change this, but it's impractical for all but the
largest organizations.

------
lmm
A secring is a "secret keyring" that contains a number of private keys. I
agree that consistency of "secret" versus "private" would be helpful, but the
concepts of a key and a keyring are distinct (and a reasonably effective
metaphor IMO - you have a keyring which your keys are on). The extent to which
the tools should push you towards having a single key versus rotating is
arguable; people criticise GPG for being too hard to use but people (sometimes
even the same people!) also attack it for not encouraging key rotation enough.
A gitflow-esque helper for setting up a best-practice rotation would be a
valuable thing for someone to make (and fundamentally there just isn't enough
money in making these tools more usable, unfortunately, which is why I fear it
will never happen).

GPG shouldn't need to tell you (prominently) where the files are because you
should never need to know that - tools that integrate with GPG should be able
to ask GPG where the keys are. The main thing that needs to happen here is for
the Enigmail key generation bug to be fixed.

If you're looking for a good GUI mail experience with GPG integration I found
KMail much nicer than Thunderbird/Enigmail, for what it's worth.

~~~
zanny
Kmail is the only GPG experience I have ever found that just worked. It has a
selection of keyservers by default, and if you email someone with a key on one
of them it just _magically uses it like its supposed to_.

Combine that with the KDE GPG manager which is also painless to generate and
upload your own key, and its the only time I have ever been able to get
"muggles" using GPG successfully.

------
Gaelan
Ooh, I know this one! I think. Doesn't Apple Mail have this built in? I go to
Keychain Access, choose the option to generate a key. Two clicks. Head to
Mail, encryption options are there. Now, to import his key. Do some googling
on that.

Wait, what? Apple Mail supports S/MIME, not GPG. Competing standards strike
again.

If the other person has S/MIME, Apple Mail does have a very easy experience. I
can't speak for the merits of either security-wise.

Also, I think this is the sort of thing Keybase is good for. There's a level
of indirection pasting into Keybase, but it's pretty easy to set up and (for
non-Snowden levels of paranoia) makes it very easy to start sending encrypted
mail to somebody else. The new Keybase chat is also an option.

~~~
dijit
I'm glad S/MIME gets a mention because I've always been skeptical of it based
on the fact that everyone rallies behind PGP.

I recently failed to install gpg2 on freebsd (for some reason it barks at me
and fails and I don't care enough to waste my time on it) and decided to give
S/MIME a chance with a signed cert from comodo. (which was free, just to try)

I have to say though the experience is beyond reasonable, it's very easy to
get to grips with. If you're using S/MIME, I see a little verified badge in my
client, not only that, if I've receieved signed mail from you, I can reply
with an encrypted document that only you can decrypt.

This works with CC's and everything. The CA cargo-cult crap definitely has a
benefit when it comes to web-of-trust.

(YMMV, I was using Thunderbird)

~~~
Psilidae
Well, this just convinced me to snag a cert for myself. Are there any services
like keybase for sharing S/MIME public keys?

~~~
dijit
No, that's the beauty. Once you emailed a person your validated cert is saved
in their outgoing keychain.

No more public key exchange. I checked and Thunderbird often checks the CRL
for the certificate I have. I also checked revocation of that certificate and
thunderbird shows a big warning about it being invalid. (although it doesn't
specify expired or revoked).

------
Raed667
I have "taught" encrypted email for many years to different types of people.

I'm surprised to see that most non-technical people that I assisted had a
better understanding of these same tools than the author.

Generating the key using Enigmail has always worked for both Windows and
Debian/Ubuntu (those are the top OSs people brought), finding a person's key
was a pain a few years ago, I love the new UI.

My conclusion: The author probably had his mind set before even starting.

EDIT : Enigmail now allows you to enable encryption/signing by default, this
prevents users from sending accidental clear-text emails.

~~~
jvdh
The author probably exaggerates, but identifies a very valid point. You really
don't want to have this kind of confusion about something that you are
planning to trust your secrets to.

~~~
Raed667
The naming confusion is legitimate (PGP, GPG, openPGP) but it literally takes
one Google query "PGP GPG" to answer that question in 30 seconds.

~~~
jvdh
The naming of "private key" versus "secring.pgp" is very valid criticism.

Also the fact that it crashes on first use, and that it is all not very user-
friendly are all valid criticisms (still!).

PS. please don't down vote because you disagree.

------
parent5446
This article: what a shitfest.

But seriously, I was expecting some actual discussion about how GPG still
isn't easy (or possible for that matter) in modern webmail clients, or even
something relating to the usability of common GPG GUIs, but instead just got a
guy complaining about how he was pressing enter too fast and missed a dialog
box, among other nonsense complaints.

Personally, the GPG CLI acts exactly as I expect it to, being a CLI and all,
and I don't expect non-advanced users to use it.

~~~
lukeschlather
A messaging standard that only advanced users can use is basically useless.
That's the point of the article.

~~~
parent5446
I agree with your first sentence, but I don't think that's what the article
was saying. (Or at the very least, it was poorly written enough such that that
did not come across.)

------
mark_l_watson
Years ago, working at a friend's security company everyone used Apple Mail
with GPG. That is the only time anyone insisted on using encrypted email.

Fast forward to the present: I support and like ProtonMail, but I can't talk
anyone else into using it. I don't understand why more small companies,
wanting to protect their intellectual property, don't use ProtonMail (or
something like it).

~~~
whodknee
Well, AFIAK ProtonMail doesn't have business accounts yet, they say they will
be adding them soon though.

~~~
nthompson
I have a business account through protonmail.

------
cpursley
I'm not sure I buy this. Protonmail has a very polished UI that's dead simple
enough for technical people and non-technical people alike:

[https://protonmail.com](https://protonmail.com)

~~~
seppin
does this only work if both parties have @protonmail.com ?

~~~
testloop
It works seamlessly/automatically between protonmail users and you can also
send encrypted mail to non-protonmail users - they receive a link via email
that they need a password to access.

You can also export your PGP public key and receive encrypted email from
anyone else too.

~~~
nickik
I like Protonmail, but its a far cry away from 'real' GPG. They are just now
adding SMTP. They don't allow key uploads. They don't let you send (gpg)
encrypted E-Mail to non Protonmail users and there are some other problems.

I wish them a lot of luck fixing and working on this stuff.

------
zamalek
This is one of the reasons that disrupting email is one of the most popular
bad ventures. It's great 1980's tech. Email is a false vacuum in the field of
solutions for communication, a local minimum. We can't improve on it any
futher - every direction along the gradient of solutions is a worse solution.

IM is doing a good job at locating a new local minimum right now.

------
vasilakisfil
The site does not use HTTPS (TLS) so that public key is completely useless.

~~~
jwilk
What is your threat model?

Is a TLA going to MITM all connections to incoherency.co.uk in order to read
OpenGPG-encrypted mails? That's not very realistic.

I'm not saying that the way the key is being distributed is perfect, but I
wouldn't say it's "completely useless".

------
jecxjo
The more this topic comes up, the more I start to wonder if the "difficulty"
in email encryption is actually people just being lazy.

We have IM and texting apps like Signal. You install, and if your friends
install then you're secure. Most people skip verifying fingerprints, not doing
IRL face to face verification. Yes the install process is simple and requires
no real work to start encrypting things, but that still doesn't make the
process secure. If anything, having these types of security models where you
aren't forced to verify the other end continues to breed this lazy mentality.
Security is hard and requires all end users to actually put time and thought
into what they are doing. We can always make a better mouse trap when it comes
to security but that will not change people's minds on how they interact with
security when online.

~~~
lol768
>I start to wonder if the "difficulty" in email encryption is actually people
just being lazy

I think it's a combination of this and perhaps some ignorance as to the
implications of skipping these processes, hence they aren't taken seriously.
I'm not sure if more education on this is the solution or not, since it seems
a lot of people don't really care about these internals and don't want to take
the time to understand what's going on. I'm not sure I'd describe this as
laziness or just stubbornness.

Users tend to be very goal-oriented and with (for example) TLS certificate
validation errors, these simply stand in the way of what the end-user is
trying to achieve. There have been a couple of studies done on how users tend
to just dismiss these errors
[http://static.usenix.org/legacy/events/sec09/tech/full_paper...](http://static.usenix.org/legacy/events/sec09/tech/full_papers/sec09_browser.pdf)

~~~
jecxjo
I've had the "security" conversation with my father-in-law a few times. He is
a wanna be computer nerd.

I tried to explain to him the benefits of all traffic being encrypted. It
means "the man" can't see anything you are doing. Why would you want this?
Because it sets a precedent that you aren't hiding something. I had a job once
where coworkers only spoke Spanish when they wanted to talk about someone
without their knowledge. It was obvious and even those who didn't speak the
language could see it was happening. If they just spoke it all the time no one
would have suspected they were making fun of someone, and no one would have
paid that close of attention to what they were saying. It would have become a
non-issue.

------
sigjuice
Most prominent mail clients have built-in S/MIME support (Outlook, iOS,
Thunderbird, Mail.app on macOS). The problem is that the there is no easy and
free/cheap way to get an S/MIME certificate. My hope is that Let's Encrypt or
Keybase or someone will make this easier someday.

~~~
Psilidae
Another comment on this article actually shows this isn't true: Comodo offers
free S/MIME certificates.
([https://news.ycombinator.com/item?id=13635591](https://news.ycombinator.com/item?id=13635591))

I went ahead and just grabbed one for myself after learning this.

~~~
sigjuice
S/MIME support has to be more widespread than just one or two providers with
free certificates. Comodo's own iOS and Android instructions do not look
straightforward at all.

Also, what happens when your certificate expires? Are you supposed to keep all
expired certificates so you can still read older encrypted email? Does that
even work?

------
tom-jh
It is indeed a pain. That's why I made
[https://cryptup.org/](https://cryptup.org/)

For some of my users, using Gmail itself is already challenging.

Yet they are sending around PGP encrypted messages, attachments, etc.

Even my mom is using this. For encryption software, moms count double.

~~~
chippy
theres something screwy with the images on the testimonials part of the page:
[http://i.imgur.com/RFoqpKwl.png](http://i.imgur.com/RFoqpKwl.png)

~~~
tom-jh
(edit: it's fixed now) First time I see it like that, I assume one of your
plugins is blocking it (direct links to google profiles). I'll store the
images & serve them directly. Thanks!

~~~
jhasse
Still not fixed for me. (Firefox with Ublock Origin)

~~~
tom-jh
Ah, Firefox. Now fixed for real. Thanks!

------
dmbaggett
It's only a pain if you're still trying to use PGP. You can download Inky
([http://inky.com](http://inky.com)) for any platform and use any email
account to exchange S/MIME-encrypted email simply by checking a button. We're
focused on large enterprises now (because we've found consumers and small
business don't care about encrypting their email, or think TLS=encryption) but
there's nothing stopping individuals from trying it out. It makes e2e
encryption of email using any email account basically invisible. You can send
encrypted mail to non-Inky users as well.

------
guenp
[https://gpgtools.org/](https://gpgtools.org/) works great for Mac.

~~~
bpicolo
For technical folk, yeah. For nontechnical folk, nothing seems to come even
close though. The great thing about HTTPS, for example, is all users need to
care about is a little green lock. (And frequently, they have no idea what
HTTPS is, but know that little green lock === safe)

~~~
nmat
> little green lock === safe

Which is not true. Little green lock means the site has HTTPS, being safe
requires much more than that. Security is hard to explain.

~~~
bpicolo
Of course, but this is nonetheless the view for typical end users.

~~~
jecxjo
And THIS is the problem. Yeah the app is a pain to install, but security is a
mindset, not just an app.

I even wonder how many people download an ISO or installer from a website, and
do any sort of due diligence to find the signer's key from another 3rd party
location, then verify previous builds, or require multiple signers of a key to
give any semblance that the key is not fake? Or do we all just download the
ISO and the .iso.asc file from the links provided and call it good? Even
security minded people can be lazy in this situation.

------
cottsak
Well now there's Signal [https://itunes.apple.com/au/app/signal-private-
messenger/id8...](https://itunes.apple.com/au/app/signal-private-
messenger/id874139669) and Keybase Chat [https://keybase.io/blog/keybase-
chat](https://keybase.io/blog/keybase-chat)

Why do we still need PGP email?

------
parennoob
Do any of these keyservers perform email verification? It would go a good way
towards _some_ kind of verification that a user's GPG key corresponds to their
email. Otherwise, anyone can generate a key with any email address and push it
up to the servers. The standard way of verifying it (key-signing parties) is
somewhat difficult.

~~~
raesene6
To me a more useful model is the one implemented by keybase, where a number of
proofs are provided, tying a specific key to the user's online identity (e.g.
github profile/HN profile).

Many times I want to "communicate with the persion identified as X on site Y"
and this allows that to occur.

~~~
dredmorbius
I've seen keybase and 1) cannot understand it or 2) understand its use-case.

I don't associate online identities with my primary communications, generally.

------
matt_wulfeck
It's not _hard_ though, it's just hard to do it without any third-party in a
way that provides an easy user experience. iMessage is a good example of
encrypted E2E messaging that "just works", but it is setup and maintained by a
third party.

I would say one of the biggest hurdles to increased security is the
debilitating nature of secure from the security people themselves. Everyone
wants a _perfect_ solution and postulates endlessly about every edge case. So
much so that the community won't accept any solution that has even a little
bit of hair on it, so nothing gets done except everyones individual homebrew
mechanisms. I swear there's not a pragmatic bone in their bodies, and if you
doubt me then join some popular crypto mailing lists and see the tinfoil
hattery for yourselves.

------
cookie0
Your key is not importable :D

    
    
      $ gpg --import stanley.asc
      gpg: CRC error; C68D2A - 29357C
      gpg: read_block: read error: Invalid keyring
      gpg: import from `stanley.asc' failed: Invalid keyring
      gpg: Total number processed: 0
    

Edit: Your key is way too short.

~~~
jstanley
This was my mistake! It's not too short. I search-and-replaced my h2 tags with
h3, which broke the key. Oops.

I've fixed it now.

~~~
cookie0
Now it works, nevertheless it still is (too) short, because you are using a
soon-to-be insecure key size:

[https://www.gnupg.org/faq/gnupg-
faq.html#default_rsa2048](https://www.gnupg.org/faq/gnupg-
faq.html#default_rsa2048)

"In 2010, France’s Agence Nationale de la Securite des Systems d’Information
stated they had confidence in RSA-2048 until at least 2020."

~~~
jstanley
:( That was the default size suggested to me by gpg.

~~~
gcp
2048-bit RSA keys are still very common and the least of your worries for
quite a while.

------
cygned
A client's admin sends credentials via email - including logins and passwords
for mission critical infrastructure. When asking him about security concerns
he said: "Our mail server's using HTTPS, everything is secure"

I haven't responded to that.

~~~
andai
Noob question: what are the problems here? Mail server being compromised,
and/or any of the sender/recipient machines?

------
Tepix
gpg2 broke when I updated from Ubuntu 14.04 to Ubuntu 16.04. I had to export
the keys using gpg and import them using gpg2.

Before the upgrade gpg2 was able to read the keys just fine.

Now, that's not the only problem after the upgrade, Enigmail is having some
other issues...

It's a mess.

~~~
mjevans
The problem was likely that gpg2 made a /copy/ of your gpg(1) keyring when it
first ran. After that they were out of sync.

gpg2 really just needs a gpg1 comparability shim that's good enough that it
/replaces/ the gpg1 tools on a system and seamlessly gets them to use the gpg2
keyring.

~~~
Tepix
Not sure. I was already using gpg2 with Ubuntu 14.04 so I see no reason why it
would stop to work.

------
makecheck
If you want more-secure methods adopted, they have to be easy to use.

I find that encrypted PDFs are a reasonable option, even when reading on
mobile.

If I want to send myself something sensitive, I attach a password-protected
PDF; then even if I open the “E-mail” on my iPhone, I am prompted for a
password before I am allowed to view it.

And frankly, I wish that web sites would stop trying to implement their own
clunky mail-like “secure” messaging systems and just use password PDF. I
_hate_ receiving these “you have a secure message on oursite.com!” messages
that are impossible to deal with on mobile (not to mention they appear very
spam-like at first).

------
innocentoldguy
I used to encrypt my email with GnuPG, but it was a huge hassle for me, and an
even bigger pain for the family and friends I wanted to communicate with. In
the end, I realized that the things I tend to say over email just aren't that
important anyway, so I stopped doing it. If someone wants to spy on my dad's
fart jokes, more power to them.

Nowadays, I hardly ever check my email. There are other ways to communicate
with the people who matter to me, which are automatically encrypted and aren't
as easily exploited by marketers and spammers. Email just isn't something I
really need or use much anymore.

------
zanethomas
Protonmail works fine for me. I prefer to keep e-mails within family and with
other close associates private. So I just insist everyone uses protonmail.
It's as easy to use as gmail and they all put up with my demands.

------
phyushin
I wrote a blog post on using mailvelope to send/receive encrypted emails via
existing mail providers such as Google mail ... Linked into my post about
getting a private/public key pair using keybase.io I'd like to think they
explain it fairly well but I hadn't considered the implications of people
believing they're more secure than they actually are ... Until I read the
comments here - disclaimer: not claiming encrypted email is super secure or
even necessarily that using mailvelope is super secure but just wanted to make
it look less scary to the uninitiated

------
spodkowinski
What I find most frustrating when it comes to GPG encryption and email is the
lack of support for public key encryption for generated mails. I've seen very
few sites supporting GPG and if they did, I found it always just worked and I
imaging not much of a big deal to setup. So why do even the biggest shops not
offer this? I really would like to be able to upload my public key to e.g.
Amazon. It's great to make the checkout process and everything super secure,
but just to send every purchase you did and your personal data in an
unencrypted mail across the web afterwards.

------
iofiiiiiiiii
The main challenge for me seems to be that users do not have a concept of
maintaining a digital identity and the key management that goes along with it.
They just expect their real world identity to somehow translate automatically.

This just does not happen. Though I wonder if government-issued digital ID
might be of benefit here to encourage good practices. Estonian ID-cards carry
key pairs, so if email clients supported GPG email with smartcard-hosted keys
(uhh maybe some do but I never heard of one) then this might be an approach
worth undertaking.

------
nkoren
...Or you could just use [https://www.mailpile.is/](https://www.mailpile.is/),
which is a genuinely less painful way to do encrypted email.

~~~
HerraBRE
Thanks for the shout out. We're not ready for public consumption yet though,
still working on it. We always need more developers and "skilled" testers
though!

~~~
andai
Wow that looks great! I'll keep an eye on this :)

------
whyagaindavid
I want email to stay at least for work related. Imagine your employer shifts
to WhatsApp or signal. Asks you to code shady stuff. Even if you resign, there
is no proof your manager knew it if your official mobile phone was wiped.
Think about harassment from senior managers. All these go undocumented. This
is why I prefer my email from and to every one in office to be plain text. No
PGP. I am German; do not care Hillary or Trump - but if Hillary had used
signal. May be things would be different!

------
aarontyree
Keybase, Nylas mail plugin. Done. or GPG Tools beta, Mail app, done. or even
just the Keybase built in encrypt/decrypt.

~~~
sabarasaba
I wanted to give this a go, I downloaded nylas but there aint no Encryption
plugin or anything. How do you go about configuring it ?

~~~
spang
For now, the encryption plugin is only available on the older version, Nylas
Pro. No reason for that other than time to port and QA the plugin to the new
free version, which has a completely written mail sync engine that runs
locally rather than in the cloud. We're working on porting all Nylas Pro
features to the new version as fast as we can!

If you want to keep up to date about the latest features, you can sign up for
our newsletter at the bottom of this page: [https://nylas.com/nylas-
mail/](https://nylas.com/nylas-mail/)

------
jheriko
to me, this accurately describes most user experiences of most open source
software.

its not just gpg and mail encryption, this sort of experience describes a lot
of tools - and not too long ago just installing linux was a considerably worse
nightmare of usability fails than this (it has greatly improved, i'm happy to
say)

------
logfromblammo
I think the real problem is real-person identity management. Encrypted email
is still a pain because we're still trying to shoehorn secure communication
into a system that is fundamentally open and public, and filled with
authorities that have to know something about you in order to route your
messages to somewhere closer to your mailbox.

Email is still the text equivalent to the publicly switched telephone network.
Domain names have to be registered. Mail routing has to be set up via DNS MX
records and mail server software. It is like writing a letter on a postcard.
Any attacker will be able to read the origin postmark, the destination
address, and the ciphertext, no matter what code you use for the message.

All the problems with key exchange and trust chains is a result of trying to
send secure messages from one known person to another known person. It's
approaching from the wrong direction. People meet in person to grow their web
of trust before exchanging secure messages online. But most of the people I
communicate with online, I have never met in person, nor do I even know what
they look like.

If I use secure pseudonym-to-pseudonym communication to set up an in-person
meeting, and prove to the other that the human controls the pseudonymous
identity, it should be impossible to determine how those two real people
happened to show up in the same place at the same time. It should be
indistinguishable from a coincidental encounter. You just can't do that with
encrypted email.

I envision an uncountable number of large rocks, and masked ninjas running
around hiding encrypted notes under them. The ninjas hang out in their
darkened ninja bars, letting each other know which dead drop to use if they
want to start a correspondence, and how to signal that it should be checked.
But in the network, nothing exists unless someone runs the service, so all
those rocks would have to be created and maintained by volunteers, and there
is always the possibility that someone is preferentially using one of their
own rocks, or setting up a fake rock to spy on anyone that lifts it.

I don't even know enough cryptography or spy tradecraft to even make a helpful
suggestion on how to communicate with anyone on the network in such a way that
all known attacks by state-level actors may be mitigated. All I can think of
is the Black Hand missions of Oblivion (Elder Scrolls 4)--which used dead
drops--and I ended up spoilering all the spoilers, because they had been
spoilered. Never mind the philosophical implications of questioning how you
even know whether a person you are talking to face-to-face, whom you have
known for years, is really the person they appear to be. Do we even need to
attach an identity to an actual face most of the time?

------
duracel
Why would spy agencies wanted to read people's messages from server, when they
can get plain text in each device ? Nonsense. Current encryption type secures
only storage and transmission states. What secures kernel, decryption, caching
and read states ?

~~~
nickik
Economics.

Attacking all end devices all the time is incredibly difficult. It simply not
economically practical.

So we need to secure all communication and all data at rest. That's most
important. Fixing all bugs in all end user devices is a hole bigger problem
(or doing something to avoid escalation). It is getting a lot of attention
too, for example Linux Kernal Hardning project). People switching languages
away from C also helps.

------
brynjolf
After the second shitfest he lost me. Colourful language sure but this just
felt out of place.

------
patrickread
If you're OK with using a third-party and would rather stick to GUI's, Virtru
is a very easy solution for email encryption:
[https://www.virtru.com/](https://www.virtru.com/)

~~~
tptacek
Where by "email encryption" we mean "mail people a link to a service they can
register with and then upload messages and file to, so that SMTP is used only
to relay links to messages, not the messages themselves, and email is
encrypted by dint of TLS connections".

That's what most F-500 companies do to solve this problem. It's a more viable
approach than direct encryption of PGP.

Normal people --- and eventually the F-500's, too --- just use WhatsApp.

~~~
pdog
_> Normal people --- and eventually the F-500's, too --- just use WhatsApp._

Sure, but WhatsApp is a totally closed protocol owned by a company (Facebook)
known for rampant issues with privacy.

Security professionals have a responsibility to recommend open protocols like
Signal that are dedicated to privacy.

~~~
tptacek
This is the "have you stopped beating your wife yet" of security arguments.

~~~
reitanqild
You usually seem like a very smart and reasonable man but here I _feel_ you
are missing major parts of the picture and I don't understand why you would.

Given what we have seen from Facebook so far I am not convinced they wouldn't
sell data to anyone including Hitler as long as they paid for it somehow.

More realistically though I fully expect them to sell (misleading) data to
insurance companies, Indian (and other) support scammers etc without asking
many questions.

For that reason I prefer almost anything including email and Telegram.

(My opinions might be somewhat coloured by the fact that I was an enthusiastic
Whatsapp user before Facebook bought them and even stayed and gave Facebook
another chance with Whatsapp. )

~~~
wolf550e
Facebook see your whatsapp contacts (social graph) and can sell that, but they
really can't see the content of conversations.

If being known to be in contact with certain people (e.g. human rights
activists) can be damaging to you, you need to use something other than
whatsapp or to somehow make sure the phone number whatsapp knows cannot be
connected to your identity.

~~~
reitanqild
_Facebook see your whatsapp contacts (social graph) and can sell that, but
they really can 't see the content of conversations._

Exactly the problem. My conversations should be utterly unexiting for anyone
capable of getting hold if them.

I am personally more worried about FB selling (misleading) data to insurance
companies. If their ad targeting is at the same level as everyone else they
could get whatever conclusions they want from whatever data.

And then there is the issue about actual human rights activists and while I am
not very active (monthly payment to amnesty) I don't want to _support_ a
system that scoops everyones data into the hands of "they trusted me"
Zuckerberg.

Even worse I was with Whatsapp and gave Facebook another chance until it was
clear that datamining everyone was the _only_ reason they bought the company.

------
alkonaut
Using encrypted email is only a solved problem (simple enough) when it's as
easy as using https for all end users.

Right now it's on par with _serving_ https, which is still way way too painful
even for tech people.

------
aruggirello
I don't know what kind of Linux the author is using but, on
Debian/Ubuntu/Mint/etc., you should really be doing:

    
    
      sudo apt-get install enigmail
    

rather than go hunting for installers.

------
faragon
You can not avoid responses in clear-text quoting your encrypted emails, so
that mechanism is broken by design: it should be a point to point encrypted
mailbox.

------
known
[https://securedrop.propublica.org/](https://securedrop.propublica.org/) FTW

------
nickpsecurity
Let me contrast the author's experience with my own. Note that I had a brain
injury during this process that made me forget scripting and GPG plus hard to
learn. I'm a nice test case for how hard things are. :)

So, I looked into GPG. Holy shit there's a ton of options and complexity.
High-assurance security says subset to minimal thing that works for increased
trustworthiness. I noticed it could encrypt files with others' public keys.
The person that contacted me was able to receive attached files. Text editors
only have so many 0-days left in them & are easy to sandbox. So, I decided on
this protocol:

1\. Type the message into a text file.

2\. Type a cryptic command to encrypt it with that public key.

3\. Attach the file to a message to that person. Optionally doing this on a
different box passed through a data diode if I was worried about GPG box
compromised. Just using Linux for now.

4\. Receiving works other way where I download an encrypted file that I run a
decryption command on.

So, that's simple. How to get started and what commands to use? I installed
GPG first. One look at the man page made me hit Google instead. I found a
cheat sheet, identified the minimal commands necessary, and compared them
against the man page. Saw what seemed to be right stuff but that man page was
horrible. Looked at a bunch of other sources online with varying
trustworthiness to see if they had same commands. Seemed like I had the right
ones. I was also warned the key gen phase could take a long time so I just
ignored that usability problem that stomped the OP so much. I was warned after
all.

The key generated. Messages sent and received well. Only thing left was
tediously typing my new buddy's email into the box with every encryption. As
others came up, I was having to remember more email addresses. Time to
automate that shit with a front end that worked on any system I needed. Also,
without remembering how to program.

I recalled Python was easy. So, I'd need a data structure for a list of
(alias, email) pairs, basic operations on text for maybe substitution, input,
conditionals, ability to print them, and spawn function of some kind. Python
reference gave me all I need which I tested each to be sure then composed them
with tests. End result was a Python script with the list of alias/emails in it
like a config file where I could just add people to the script itself. Then, I
run the script on the text message with it asking which of a listed group of
people to send it to. I type in number or name for it to run command
automatically. Then, I verify by eye the new file looks like gibberish and
attach it to the email.

End result was that I had GPG for friends using it, I figured out how to use
it with fair degree of trustworthiness, and I automated the annoying part with
less than beginner's knowledge of scripting. This shows GPG is way less hard
than it appears to be. Although I sure could use a great front-end to smooth
over all this. I'm sure any half-ass programmer could create one given what I
did in that state. :)

~~~
Jach
I made this pretty quickly:
[http://kuuv.io/i/L4rZomr.png](http://kuuv.io/i/L4rZomr.png) Slower than if I
just used Python with tkinter since I wanted to learn a new UI framework with
Clojure at the same time... But it's literally just a dropdown and some
buttons wrapping some system calls to 'gpg'. I never bothered with the
'decrypt file' since I can remember 'gpg --decrypt' easily enough. :)

So I agree using GPG isn't very hard, it's easy to make it even easier for
yourself, and I think its usability flaws are overblown. Unfortunately as a
comment further up said "the GPG CLI acts exactly as I expect it to...and I
don't expect non-advanced users to use it." Only advanced users use the CLI
these days. Not because it's particularly complex or hard or a poor
experience, they're just given no reason to, and no training even if they had
reason.

~~~
lmm
A GUI that wraps some system calls is how you end up using "p" for all your
passwords. One of the many symptoms of OpenPGP not getting the investment it
deserves and sorely needs is that there is no production-quality library
implementation going.

~~~
nickpsecurity
A better implementation would be nice except that it requires a ton of
specialist skill to get right. Plus lots of time. A wrapper is basically an
interface. Getting interfaces correctly can be done by knowing what it
expects, what properties should always hold, and what happens after each call.
Correctness is basically one or more state machines with assertions built in
for interactions between front end and library. _Much_ easier.

------
isaac_is_goat
ProtonMail is "good enough" for me.

------
peterposter
Couldn't the blockchain be employed to do proof-of-key-ownership? I mean it's
decentralized and trusted and all

~~~
damir
my thoughts exactly. why not have pub keys as confirmed transactions on a
blockchain?

------
upofadown
TLDR: Enigmail can be entirely broken due to interaction with GPG.

I've never used Enigmail. Is this sort of thing common?

------
throw7
Any business that approaches usefulness in terms of encrypted communications
is shutdown by the u.s.

------
Vkkan2016
I am using protonmail it's clean and secure and it's working on non proton
users with pin

------
conmarap
Or, you could just use Protonmail and be done with it.

------
owly
I love protonmail. It's simple and just works.

------
omouse
ProtonMail and TutaNota are pretty good.

------
pymai
protonmail is a whole lot easier to use now that you only need 1 password
instead of 2

------
exabrial
Keybase.io brah. Simple!

------
qplex
If you find 'gpg --gen-key' too hard to use, I don't know what to tell you.

It presents (at least on my system) a very clear prompt to type a passphrase.
Maybe you should blame your distribution instead of gpg?

