
Now I understand why almost no one uses encrypted email - sT370ma2
https://cheapskatesguide.org/articles/encrypted-email.html
======
tptacek
All of this of course skates past the problem that PGP's UX practically
guarantees that someone will eventually reply to an encrypted email in
plaintext, often compromising the whole conversation. Practically everyone who
has used encrypted email "at scale" has seen it happen. An intolerable,
irrevocable disaster we accept only because most of us don't _actually_ care
about the cryptographic security of our emails, most of the time.

~~~
brnt
Autocrypt is a sensible approach leveraging PGP but avoiding most of that
ceremonial UX. Unfortunately the gnupg project is heading in its own direction
with major clients such as Thunderbird and Protonmail following. Few clients
actually implement Autocrypt.

The group that has used PGP largely seems to like the ceremony required and
chooses not to understand it is an impediment for both pervasive encrypted
email and usability for nontechnical users. Hell even for technical users PGP
is a hassle.

I'm doing what I can to spread the word on Autocrypt, but nontech types can't
or won't switch to the few clients implementing it and the PGP fanbase sees
their 6 levels of trust as Zimmerman given dogma that must not be altered
under pressure of earthly realities, or security insights developed after the
Code was written down.

~~~
upofadown
>...the PGP fanbase sees their 6 levels of trust as Zimmerman dogma that must
not be altered under pressure of earthly realities, or security insights
developed after the Code was written down.

I am an actual OpenPGP shill who is entirely in favour of a very conservative
approach to the standard but I really don't see the problem here. Autocrypt is
a separate standard. Clients can implement it completely and just switch the
trust to OpenPGP if a PGP identity shows up. There is nothing wrong with a
client adding some extra trust information to accommodate autocrypt.

~~~
brnt
Autocrypt requires its own separate PGP contacts database (regular PGP
standard doesn't allow automatic key overwrites), and as such most MUAs prefer
to limit the number of things they support to old PGP. This is a problem for
adoption.

------
bszupnick
As someone who worked as a pen-tester, security is almost ALWAYS at odds with
convenience.

Making better security less and less inconvenient is the name of the game.
Even if 100% security would be as easy as ticking a box, though, the fact of
the matter is that most people don't care and if it's not "secure by default",
it simply will stay not secure.

Maybe a synonym for "turned on by default" is "absolutely zero inconvenience
or attention needed"

~~~
jidiculous
Honestly, this makes me appreciate Signal all the more – it seems the only
barrier is getting friends to adopt it, but if used by an organization could
it be an alternative to E2EE email?

~~~
NikolaeVarius
In my experience, the client is stupidly buggy. I've lost messages silently
multiple times. This is a known issue and after losing several key messages
stopped using it.

So, IMO the barrier is, "actually working"

[https://github.com/signalapp/Signal-
Android/issues/5253](https://github.com/signalapp/Signal-Android/issues/5253)
[https://github.com/signalapp/Signal-
Android/search?q=missing...](https://github.com/signalapp/Signal-
Android/search?q=missing+messages&type=Issues)

~~~
asdf-asdf-asdf
it probably should be mentioned that the first github issue you linked is
about signal loosing SMS-messages, not signal-messages. so for the case
mentioned by the parent (" getting friends to adopt it") it is not really
relevant.

~~~
Vinnl
One thing I've been able to tell friends is to just replace their default SMS
app with Signal, since they're not particularly attached to that app anyway.
Then, at least their messages to me will then be encrypted, and every
additional person I get to install Signal will have an additional contact
being able to use it/join a group.

~~~
QuinnWilton
This works until they either switch back to their original app or get a new
phone and don't install signal on it. If you stop using Signal you need to
deregister your phone number from the service, but many people don't know or
care to do that.

If they don't, anyone who has ever used Signal to communicate with them will
be silently unable to contact them anymore.

~~~
Vinnl
True. The former hasn't been a problem for me, the latter's becoming
increasingly less so now that more and more people have switched, and people
are starting to more consciously use it every now and then for one of the few
Signal groups we have - but it certainly was a problem at first.

------
hoistbypetard
It has very little to do with the UX of email encryption, IMO. People don't
use encrypted email because the parties who would have to do the work in order
to use it have never, and do not know anyone who has ever, suffered a problem
that encrypted email would address.

Web sites use encryption because the people who would need to do the work of
setting it up know that search rankings, user experience thanks to browser
reporting of unencrypted connections, and consumer confidence all suffer if
they don't.

And it improves their security in a couple ways too.

For encrypted email, the onus is on the recipient of email to set it up. Such
a vanishingly small number of recipients have ever suffered a problem that
encryption would solve, it might as well be __zero __.

We can talk about making the UX better. But unless it's effort-free and
happens by default, there's no motivation.

~~~
bdamm
End-to-end encryption is still a very challenging problem almost everywhere
except for direct connection server-side TLS. Yet, everyone has a problem that
encryption solves, which is that you actually cannot if some entity has been
interfering with your email, perhaps re-writing certain paragraphs. There is
plenty of evidence that actually interfering with email is in fact something
that happens. Similarly, in the age before widespread use of TLS, cases of
ISPs injecting content/javascript/trackers into web traffic was also
widespread.

~~~
matheusmoreira
> End-to-end encryption is still a very challenging problem almost everywhere
> except for direct connection server-side TLS.

Is this the case with WhatsApp and Signal? Their implementations have been
working great. Why can't email work the same way?

> There is plenty of evidence that actually interfering with email is in fact
> something that happens.

Please cite examples. I know Avast antivirus used to obnoxiously tamper with
the emails sent by users in order to spam other people with its own
advertising.

~~~
lmm
> Is this the case with WhatsApp and Signal? Their implementations have been
> working great. Why can't email work the same way?

The ratchet protocol that that approach relies on requires both ends to be
online at the same time. And those implementations haven't been working great.
WhatsApp was definitely compromisable by an attacker who had access to the
server. I have yet to be convinced that Signal couldn't be; all the
descriptions of its protocol are suspiciously ambiguous about whether the
attacker is assumed to control the server or the server is trusted (since the
server has to be involved in allowing offline messages to work). Furthermore
we've seen nothing to suggest that the NSA isn't reading WhatsApp/Signal
messages; given that those systems are tightly coupled to closed-source
ecosystems (and in particular closed-source "random" sources for key
generation) I suspect that serious adversaries aren't even trying to attack
their cryptography directly. Contrast with PGP where we know (from Snowden's
leaks) that the NSA was frustrated by their inability to break it when used
properly.

~~~
couchand
FUD. There are several critical flaws in your analysis (disclaimer: I'm an
enthusiast, not a cryptographer).

> The ratchet protocol that that approach relies on requires both ends to be
> online at the same time.

This is simply untrue, and in fact the very point of the ratchet is to support
asynchronous messaging. The next ratchet's key material is sent alongside a
message encrypted with the previous ratchet-derived shared key.

> since the server has to be involved in allowing offline messages to work

Sure, for some definition of "involved". But the relay server in the Signal
protocol absolutely does not need to be trusted for offline messages to work,
they are end-to-end encrypted.

If you don't bother to verify the security number, then you need to trust the
identity server, but that's out of scope for the protocol. Verify your
security numbers!

[0]:
[https://signal.org/docs/specifications/doubleratchet](https://signal.org/docs/specifications/doubleratchet)

~~~
lmm
> This is simply untrue, and in fact the very point of the ratchet is to
> support asynchronous messaging. The next ratchet's key material is sent
> alongside a message encrypted with the previous ratchet-derived shared key.

Not true; the point of the ratchet was to allow "off the record" conversations
where you would have forward secrecy, and also where the receiver would not
have cryptographic proof of what you said after the conversation was ended.
All of the nice security properties rely on you continuing to exchange
messages regularly; it breaks down if one side sends too many messages without
receiving a response from the other side, and as long as that time window is
open there's a risk. In practice there's a complicated risk tradeoff around
exactly how much async-ness is acceptable (both in terms of time and in terms
of number of messages without a response), but any implementation will have a
point at which it reverts to following protocol for sending the first message
to a currently-offline user.

> But the relay server in the Signal protocol absolutely does not need to be
> trusted for offline messages to work, they are end-to-end encrypted.

Maybe. It's not clear under what circumstances the server could trick the
clients into treating it as a first interaction with this user, at which point
the server is involved in the key exchange process - something that signal
security analyses tend to brush under the carpet.

> If you don't bother to verify the security number, then you need to trust
> the identity server, but that's out of scope for the protocol. Verify your
> security numbers!

This is kind of a double standard though. Good practice for using PGP is to
use regularly-rotated subkeys and destroy them once they're out of use, at
which point you don't have a forward secrecy problem. Real-world PGP users
mostly don't do this, but real-world Signal users mostly don't check security
numbers either. (In contrast, real-world PGP users do check key fingerprints,
in my experience, because the software defaults and the web of trust system
nudge them in the right direction).

------
buildbuildbuild
An emerging HN trope is that “almost no one uses PGP.”

PGP remains wildly popular on Tor cryptomarkets, an area where users assume
server compromise will happen yet still decide to transact using encrypted
messages.

Don’t underestimate a technology gaining popularity in fringe communities with
young user bases, often from non-technical backgrounds. Kudos to companies
like Keybase and Protonmail for investing in PGP’s future.

~~~
louwrentius
So you mean to say is that PGP is wildly or only popular with criminals?

~~~
exolymph
If criminals don't use your privacy tech, it probably doesn't work.

------
recrudesce
Yeah, it's tedious if you do it the long way around because you, for some
reason, have arbitrarily restricted yourself to only doing it via command
line...

Just get an email client that has PGP capability built in.

~~~
Majromax
> Just get an email client that has PGP capability built in.

That step isn't as straightforward as you might think.

Put yourself in the shoes of a complete novice. As of this writing, a Google
search for {pgp email windows} returns gpg4win as the top search result, which
is the tool the author used.

Otherwise, the software listed on the openpgp website
([https://www.openpgp.org/software/](https://www.openpgp.org/software/))
mostly _doesn 't_ have PGP capability "built in." In particular, both
Evolution and Outlook require addons for PGP support.

Despite suffering from bad UX, the instructions the author followed are
largely those present in a top-Google-searched guide
([https://yanhan.github.io/posts/2017-09-27-how-to-use-gpg-
to-...](https://yanhan.github.io/posts/2017-09-27-how-to-use-gpg-to-encrypt-
stuff.html) \-- infobox result for {gpg encrypted email}). Easier methods that
are harder to find or less obvious may as well not exist for a novice such as
the author of this article.

~~~
recrudesce
Sure, but the other weird thing is the author uses Protonmail... which can
support PGP natively, so why the fart-arsing around ?

[https://protonmail.com/support/knowledge-base/how-to-use-
pgp...](https://protonmail.com/support/knowledge-base/how-to-use-pgp/)

The whole article is basically "lol look at this thing that is actually
relatively well supported with a small amount of work, but I couldn't be
bothered to spend time doing some research about my use case and instead just
read the first google result I found, so I'm going to crap all over it and
make it look worse than it actually is for Internet Karma."

And the comment about being a novice, looking at the rest of the blog site
implies the user has some level of competence when it comes to computing
technologies as they are messing around with webserver configs etc.

------
vortico
I really enjoy articles like these because it offers a perspective that is
difficult for developers of software to see themselves. Say you're starting a
company that provides a technical service and you claim on your homepage
"3-click install!" Rarely it's ever just 3 clicks. It's a good idea to watch
videos or read written stories of every step a user takes in order to use your
service, including learning how to use it and their mistakes.

------
btilly
And the sad thing is that even if you do succeed in using encrypted email with
PGP, as [https://latacora.micro.blog/2019/07/16/the-pgp-
problem.html](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html)
says, you're taking an approach that cryptographers recommend against.

~~~
nagsil
Some cryptographers? It seems to me that this article gives all the latest and
greatest a free pass and nitpicks on PGP.

If PGP is criticized because a user could cc someone, how about taking a
screenshot from your messenger conversation?

People do this reflexively and upload almost anything.

Why would I trust a phone (tracking device) in the first place?

~~~
btilly
I have yet to run across a cryptographer that I trust whose opinion differs
significantly.

But I have no trouble finding ones that I trust who agree with the key parts
of that rant. For example
[https://www.schneier.com/blog/archives/2016/12/giving_up_on_...](https://www.schneier.com/blog/archives/2016/12/giving_up_on_pg.html),
[https://blog.cryptographyengineering.com/2014/08/13/whats-
ma...](https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-
pgp/), [https://dev.to/artis3n/encrypting-files-in-a-post-pgp-
age-59...](https://dev.to/artis3n/encrypting-files-in-a-post-pgp-age-59bf) and
many, many more.

Whether or not you can trust your phone doesn't change that PGP is missing
nearly 30 years of what we've learned about best practices for encryption.

------
08-15
> Each public key must be signed before messages from the owner of that public
> key can be decrypted.

Nope.

> Your public key must be sent to anyone to whom you send an encrypted email.

Nope, you need theirs.

I get it, in the current year, it's cool to bash gpg because it's sooooo
complicated. There may even be some merit to that argument, but it's pretty
lame if the argument is based on not understanding the very basics of public
key cryptography.

~~~
pinfisher
Seems like you are one of the only ( few ) people who caught this.

------
cryptonector
The UIs are terrible.

Indexing encrypted email -> difficult. Do it on the server-side and you're
essentially storing the email in plaintext on a server -- you might as well
have settled for hop-by-hop encryption, which is what MTAs basically try to do
anyways.

Multiple devices -> yeah, that's tough too. They need the private keys. They
need to keep their own indices.

End-to-end encrypted email is likely not workable. I'd settle for having hop-
by-hop secure email, with a "make it secure" button on send so I can have MTAs
bounce when they can't forward securely, and a "secure"/"insecure" label on
inbound email that captures whether the whole path inbound was secure or not.

Another thing is that end-to-end security in general depends on introducers.
CAs, etc. Meaning that the security that users who don't understand these
things (99% of users) have in mind is just not what they're ever gonna get in
most or all cases.

------
mikece
While there is a point to be made about PGP not being user-friendly, what's
wrong with having a free ProtonMail account (or creating a burner account if
you're paranoid), uploading the other person's public key, and having an
encrypted email exchange that way? Yes... you're having to trust that
ProtonMail is actually secure but I haven't seen anyone seriously suggest that
it's compromised.

That said, how hard would it be to create a fork of Thunderbird that has all
of the PGP stuff build in and all you need to do is upload your private key
and add a contact's public key in their address book and have an option for
"always use encrypted email" (or does Thunderbird already do exactly that and
I don't know because I don't use it)?

~~~
7786655
There's an addon called Enigmail that does exactly this.

------
AdamJacobMuller
With GPG, sure.

I have GPG keys (for other reasons) which I never use for email.

On the other hand, using S/MIME for email signing and encryption is a
pleasure. At $JOB everyone get's an email cert via self-enrollment, user
public certs go in AD, I can easily send encrypted email to anyone in our org.

------
pge
isn't the bigger issue that encrypted email is only encrypted in transit and
not in place? After you send an encrypted email and it is decrypted on the
other side, odds are very high that it is sitting unencrypted on the mail
server or local mail client. Most email breaches are not intercepting emails
in transit but rather getting credential access to email servers.

~~~
ipython
Not in this case. PGP mail or S/MIME are encrypted end to end. That said you
may have a mail client which stores an unencrypted search index locally.

------
sbuk
Another issue with encryption is the other aspect of security; malware
detection. Since E2E encryption happens at the MUA level, and most
spam/phishing/malware scanning is done either at the MTA level or by a
gateway, detection becomes almost impossible. MUA would need to do all the
extra heavily lifting. Email was designed as a plain-text messaging system.
PGP, MIME and S/MIME are extensions to this, but fundamentally, email is still
plain text. The key to secure email is not to use email for secure things.

------
austincheney
Encryption on the web is easy, because its automated by TLS. A far more
concise answer is that email does not have an equivalent to TLS because it's
architecture is not the simple client-server model like the web.

TLS is two layers of encryption. An outer layer using some form of PKI to form
an encrypted pipe for the transfer of a symmetric key transfer then a more
secure inner pipe based upon the symmetric key.

[https://en.wikipedia.org/wiki/Transport_Layer_Security](https://en.wikipedia.org/wiki/Transport_Layer_Security)

That is vaguely straight forward to automate provided lots of agreement around
various supported standards, because the client only has to communicate with a
server that will automatically respond.

Email architecture is more like client-server-server-client (and that
understates many edge cases), or rather peer-to-peer with a variety of
decentralized servers in the middle and the clients aren't stateful
applications like how web browsers are dedicated to browsing the web. An email
client on one end has no idea what the various servers and remote clients will
support and when they will ever respond for a variety of technical reasons.

Since email does not have TLS key exchange is manual unless both clients are
on the same server and the server owns the process for establishing key
exchange, session encryption to each party, and routing between each encrypted
session.

~~~
Shendare
I am a layperson, so the answer is probably painfully obvious, but why can't
e-mail have TLS-style key exchange, where the sender's server gets the public
key from the recipient's server and encrypts the message with it before
sending it over?

The recipient could keep their private key secure so that only their client
could decrypt the messages, and take the risk of losing access to those
messages if they lose their private key.

Or they could let their provider hold onto a copy of the private key so they
don't ever have to worry about losing it, with the trade-off that the provider
could decrypt their e-mails.

But either option requires zero user interaction on the sender's or
recipient's part past "login and send" or "login and receive", while limiting
decryption to the recipient and maybe their provider.

~~~
boneitis
You could, but you're dropping the qualification of end-to-end encryption.

Brainstorms of a (mere) hobbyist:

Some might reason that that yields additional hardening to traditional TLS-
enabled webmail applications.

On the other hand, that is more architectural design and work shifted away
from the endpoints (and wasted, complex efforts with no added benefit if
improperly implemented by the provider).

~~~
boneitis
One more brainstorm,

The provider can serve key escrow and still have the end-user application
perform the encryption, which may or may not technically qualify. It certainly
wouldn't fly without skepticism in a popular service/standard.

I haven't looked into it deeply enough to present a confident statement either
way.

------
lgeorget
Well, there actually are decent graphical interfaces for GnuPG and plugins for
email clients. Doing all of this manually in the shell is not a requirement to
use encryption.

------
robertlf
Maybe just use protonmail? I'm no security expert but they do claim to encrypt
all emails between users on their platform. It's alot easier than this.

~~~
markosaric
True. It's as easy as sending any other email there. I love when that little
icon on ProtonMail lights up for end-to-encrypted but it only does that when I
send mails to other PM users which are very few in total.

------
unnouinceput
Quote: "Next, I tried exporting my public key to a file. Your public key must
be sent to anyone to whom you send an encrypted email. The receiver of your
message needs it to decrypt your message."

Wrong. You do need to send your or publish your public key in order for others
to send you encrypted email. Messages are encrypted with public key and
decrypted by you with your private key.

This is the very base that async crypto is based on.

~~~
tyingq
That really only reinforces the headline though.

~~~
yarrel
Hardly. It makes the headline something we can ignore. Much as if the author
complained about driving their car into a tree because the steering wheel
wasn't giving them feedback.

~~~
tyingq
I don't imagine, if I picked 100 random people off the street, that they would
get it either.

~~~
unnouinceput
And since we live in a modern world with integration of social services only
going up I strongly believe this should be taught in school, same way base
computer usability is being taught in middle school. In there a simple chapter
should exists to deal with this and make kids aware that cybersecurity is a
must nowadays.

Then, and only then, your phrase will be false.

------
Forbo
So is Autocrypt doomed to languish in lack of adoption? While it may not be
perfect, it seems better than the current state of affairs.

~~~
tzs
We tried something like that at a place I worked in the late '90s and early
'00s. It was for Windows users.

It inserted itself between your email client and your SMTP and POP/IMAP
servers.

When you installed it, it generated a public and private key pair for you,
storing them both in your local key ring.

It would place your public key in the header of your outgoing mail, and add a
header that identified itself.

If you had enabled signing, it would transform you outgoing mail into a signed
outgoing mail.

If the mail was going to someone who was known to use this software and whose
public key was in your key ring, it would then transform your outgoing mail
into an encrypted outgoing mail.

(For mail to people who were not known to have it, it put a little blurb at
the bottom of the message suggesting they get it).

For incoming mail it would check the header to see if the mail was from
someone using this software. If it was, it would look for their public key in
the headers and add it to your key ring.

If the mail was encrypted, it would transform it to plaintext. If it was
signed, it would check the signature and put something in the message to tell
you if the signature check had passed or not.

The marketing people had more sway than the engineering people, so if
something came down to ease of use vs. security ease of use had a good chance
of winning. The marketing people were really pushing the notion that it was
"transparent", and so wanted minimal configuration and minimal interaction
with the user. They wanted you to just install it, get your friends to install
it, and have it then transparently encrypt the mail between you and your
friends.

I don't know if such a system can be made reasonably secure, but I'm pretty
sure that _if_ it can be, it's going to have to be at least somewhat intrusive
now and then. It needs to warn you if someone's key has changed, and provide
some way for you to do an out of channel verification that the change is
legitimate. There also should be some way when composing a message to indicate
that it should not be sent unencrypted, and if you attempt to send it to
someone whose key is not known it should be rejected.

(I'd even argue for an for flipping that last--a way to indicate that a
message does not need to be encrypted, with it generating an error to try to
send a message not so marked to someone whose key is not known. It should
require a deliberate choice to send an insecure message rather than the other
way around).

The way we inserted between the mail client and the SMTP/POP/IMAP server at
first was to have our software run SMTP/POP/IMAP proxies on 127.0.0.1, and
require the user to manually change their client configuration to use our
proxy.

Not long after that was changed to automatically do that for various popular
email clients. This was on Windows so for most of them that just meant some
registry editing. I think there may have been one or two where it involved
editing an actual configuration file.

I think we eventually replaced that with an LSP [1], which required no changes
to email client configuration. (I may be misremembering that part, mixing it
up with the LSP that I am sure we used for another product we had in the same
general time frame, a pre-fetching caching web proxy).

Anyway, while technically interesting I'm not sure there is really much use
for this kind of thing. You need users that need security but don't need it
too badly, and are only worried about messages in transit. But it generally
takes a pretty serious adversary to get your messages in transit--if you are
facing that you probably need some more certain security, not something that
is opportunistic.

For most people it is security at the ends that matters. It's your
siblings/parents/spouses/roommates that you have to worry about, and this
system doesn't really help against them.

[1]
[https://en.wikipedia.org/wiki/Layered_Service_Provider](https://en.wikipedia.org/wiki/Layered_Service_Provider)

------
MR4D
Encrypted mail will not be “solved” until Google, Yahoo, & Microsoft decide
you do something about it. Until then it’s just a pipe dream.

Yes that’s harsh. Yes that’s what I truly believe.

And yes, unfortunately I’ve been right about this since 2005 when arguing
about it with a colleague (Although I may not have mentioned Gmail in the list
back then).

------
leephillips
I realize that this is a bit of a jerk take, but it seems that the author's
problem is less with GnuPG and more with his reluctance to be careful and read
a little documentation. I still have the first key I made in 2001, when a
friend and I decided to try the system out. It worked the first time for both
of us, and we happily exchanged a few encrypted emails. And that was the last
time I actually used it - not because it's hard to use, but because nobody
uses it, and I don't need to send encrypted email to myself. For about 15
years I've had an X-PGP-Key: header on my outgoing mail, pointing to a file on
the web containing my public key. Not a single person has ever used it.

 _EDIT_ : No, I remember once, a few years ago, somebody did send me an
encrypted message using my public key, for no particular reason. It was an
amusing surprise.

~~~
beebob
For me this fits the narrative. Encryption needs to be transparent to the user
in order to become ubiquitous. I assume most people are actually reluctant to
read the documentation. If the tool is not self explanatory or fully embedded
in the tools people use they will not see any broader adoption.

It too managed to use the tooling. But I knew what public-key cryptography is
and was aware of its general concept. I do not expect anyone in my family to
be able to set this up. Not without putting some time into it. And putting
time into it they will only do if I pressure them to do so.

So I would say: Yes you are correct that he could have read the documentation.
But from a UX perspective I do not see the failure on the part of the user.

~~~
leephillips
Fair enough.

------
pkilgore
These two ars technica articles are a really good breakdown on both sides of
the issue, but I agree with the first.

Use keybase. It's easier!

[1] [https://arstechnica.com/information-technology/2016/12/op-
ed...](https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-
up-on-pgp/) [2] [https://arstechnica.com/information-
technology/2016/12/signa...](https://arstechnica.com/information-
technology/2016/12/signal-does-not-replace-pgp/)

------
myu701
I wonder if said acquaintance had started with something like Tutanota or
DeltaChat, if the user would have had a less frustrating experience.

This sets aside that OP wrote that they didn't want to swap email providers,
which I agree with. DeltaChat lets you use whatever provider you want, but it
is in a mobile app format and can only use one account at a time.

If they could make DeltaChat support multiple accounts and while we're pipe-
dreaming, a desktop version, I would use it for almost all non-Signal
conversations, real emails or otherwise.

------
badrabbit
Sorry but this is not about encrypted email but the sheer suckiness of GPG.

PGP enccrption works flawlessly with protonmail. I've created a word document
constituting about 5-10 screenshots of how to setup s/mime on outlook/windows
for people who know little of it and it worked with minimal issues.

However GPG is the one tool that I find has just about the worst UI.

That said, I think we should tell people to switch to E2E messaging where
possible and email needs a replacement, not another layer of complexity.

------
upofadown
Whatever guide they were using must of been terrible. Unfortunately they
failed to specify which one it was so it is hard to know what went wrong here.
Still, as learning experiences go this could of been much worse.

I suspect that most people would just of used some sort of email client with
this stuff built in rather than doing it completely manually...

~~~
mannykannot
So what guide would you recommend?

~~~
upofadown
Riseup.net has a fairly extensive discussion:

[https://riseup.net/en/security/message-
security](https://riseup.net/en/security/message-security)

FSF is a bit more to the point for the casual user:

* [https://emailselfdefense.fsf.org/en/](https://emailselfdefense.fsf.org/en/)

It is not always clear to the casual user if they are using gpg1 or gpg2. You
pretty much always want to use gpg2. This is a genuine issue with the gpg
ecosystem.

------
galaxyLogic
Why can't secure email be based on simple https-server?

I assume the server would need to store the messages in plain text, or maybe
not, but the communications to and from the server should be safe with https,
no?

You would not need to trust such a web-server any more than you currently
trust you email provider. But it would be much safer. Why not?

------
hprotagonist
"Here's my burner number, hit me up on Signal."

job done, assuming you want to transmit files under 100 MB/message.

~~~
buildbuildbuild
Safe communication in 2020 does not require buying a tracking device and
sharing its ID number.

------
missingrib
>And, unless you are someone like Edward Snowden with huge secrets to reveal,
probably no one will be willing to expend the effort to hold an encrypted
email conversation with you.

Not to mention even Glenn Greenwald did not expend the effort to learn GnuPG,
even when Snowden sent him a 10 minute tutorial.

------
throw7
I can feel the pain reading that post.

I'd suggest it might be easier and "good enough" to just use symmetric
encryption. Tell your friend the password you both will use and just use "gpg
-c plaintext.txt".

~~~
cuspycode
Or even "zip -e", for people who don't have gpg installed. I use this all the
time. It takes care of 90% of my needs, and even non-technical people
understand how to deal with it.

------
PacifyFish
I consulted for a company named FlowCrypt last year. Best email encryption UX
of any I've seen. Open source and free-for-most business model.

Highly recommend for personal use.

------
musicale
It seems like a very bad design that email messages from criminals and
scammers are virtually indistinguishable from email messages from your bank.

~~~
cryptonector
Criminals and scammers sure like that though.

------
mD5pPxMcS6fVWKE
GPG4Win has a GUI for keys and an Outlook plugin .. went smoothly for me. I
have had enough of command line interface in my Micro VAX days)

------
admax88q
Is it already time for the weekly "GPG has a bad interface" blog post?

------
0xff00ffee
This article ignores certified email built into almost every email client.

I recently experimented with Thunderbird and Mac Mail because I wanted to set
up encrypted email, and I wanted to move from GMail to one of my domains
through RunBox.

Both clients are set up for encrypted email through certificates. The UI is
pretty slick in both cases, the docs looked pretty clear!

What I found as I tried to send an email saddened me: obtaining a signed
personal certificate with a CA is nigh impossible (self-signed is easy, but
useless). I have some friends in the military who's certs are on my keychain
because they are signed by .mil, but for us schlubs? There's really no
alternative that I could find that is trusted.

Seems like if personal certs could be offered by a reliable CA, it would be
pretty damn easy to use encrypted email.

~~~
inetknght
I'm lucky enough to still have a job in a crisis. If that weren't the case,
then a pet project of mine would be a LetsEncrypt-like service for personal
certificates. Certificates you could install in your browser for TLS
authentication, and some templates and examples showing how to configure nginx
to authorize clients using one. I imagine email would be pretty similar. I'm
just not as familiar with how to configure email clients to use certificates.

~~~
floatingatoll
There were several free SMIME certificate providers, who would issue you a
personal certificate verifying that you control a given email address.

Most have shutdown their free products in the past few years, I suspect as a
result of having to invest money in their decades-old web applications that no
longer function correctly in modern browsers.

One remains, but this blog post warns that they practice unsafe private key
practices, so I'm inclined to suggest that none do.

[https://davidroessli.com/logs/2019/09/free-smime-
certificate...](https://davidroessli.com/logs/2019/09/free-smime-certificates-
in-2019/)

------
trishankdatadog
15 minutes could save you 15% on your cybersecurity insurance or more:
[https://github.com/DataDog/yubikey](https://github.com/DataDog/yubikey)

~~~
boromi
macos only guide? What about windows users?

------
floatingatoll
Secret decoder rings are cool, but they're not popular and they never will be.
Most people just want a glued envelope and a locked mailbox, not ciphertext.
If you want to advance the cause of encrypted email for everyone, and you
operate a mail server, make sure it sends and accepts encrypted SMTP
connections.

Which of these 'encrypted email' use cases is the one that's desirable to
people with regards to email, using postal mail as an analogy?

1) Letters to you can only be read by you, using a secret decoder ring to
ensure that no one else can.

2) Letters to you will usually only be read by you, unless someone takes the
letter from your mailbox and opens it.

3) Letters to you will usually only be read by you, unless the government is
spying on you and X-rays the envelope in transit.

4) Letters to you could be read by anybody and that's fine with you, since
they're openly written on the back of a postcard by the sender.

Loosely, these analogies translate as: GPG is #1, TLS SMTP is #2, SMTP is #3.
(There's not really an analogy for #4.)

A few years ago, Gmail finally added a simple lock icon summarizing whether an
email was encrypted-in-transit or not. SMIME (#1) is green/locked, TLS SMTP
(#2) is gray/locked, SMTP (#3) is red/unlocked. This single icon has probably
done more to advance the cause of encrypted email than the previous twenty
years of PGP/GPG, and the number of red icons in my email has fallen
dramatically over time.

That feature was discussed on HN at the time (4 years ago, 209 comments):
[https://news.ycombinator.com/item?id=11067050](https://news.ycombinator.com/item?id=11067050)

~~~
nybble41
> 2) Letters to you will usually only be read by you, unless someone takes the
> letter from your mailbox and opens it.

That's not a great analogy because removing a physical letter from your
mailbox and opening the envelope leaves physical evidence of tampering. It's
also a felony, with a disproportionately severe punishment, if you're not the
designated recipient of the letter. Reading an email at rest on a server
somewhere leaves no evidence that the content was leaked and is unlikely to be
punished. In the absence of physical evidence when a message is intercepted,
or practical recourse when the privacy of the communication is violated, I for
one would very much prefer option #1—end to end encryption. Frankly if there
were a system as easy as GPG for end to end encryption of physical letters,
I'd prefer that as well.

GPG does clearly have UX issues. The manually curated web-of-trust was a good
idea in principle but too much work to really catch on at scale. Encryption
needs to be enabled not only by default but unconditionally, with transparent
key exchange and some form of automatic, distributed reputation tracking. The
system that fixes these issues probably won't be built on top of SMTP or
interoperate with existing email clients, if only because encrypted email
cannot be made mandatory without breaking compatibility anyway, but it will
serve the same function of facilitating asynchronous, long-form written
communication.

~~~
floatingatoll
It's enough of an analogy to make the point, though. Most people's needs for
letters security are option #2, not option #1. If you can get the email from
source SMTP server to destination mailbox encrypted over the wire, then most
people don't care if someone _could possibly_ look at it in your mailbox. And,
very few people mind that the "lost letters" division of the postal service
opens their mail and packages to try and return it to them when something goes
wrong.

While I understand that in an ideal world, #1 would be perfect — in today's
real world, #2 would be better than the often-unencrypted mess we have today.
I've seen a lot of personal mail servers that no one set up encrypted SMTP on,
and yet their owners have GPG keys published and signed. Transport encryption
and end-to-end encryption are not conflicting goals.

I refuse to accept the defeatist view that "encrypted email cannot be made
mandatory without breaking compatibility anyway". I'm not interested in
building an encrypted utopia that doesn't interoperate with email. Every
social network and web forum for the past 20 years has tried to do this, and
none of them have replaced email at all.

I'm interested in protecting people who think that email should be safe in
transit — the same expectation that postal services give them about their mail
today — by seeing everyone who operates an email server enable transport
encryption. It's not a big ask, and it doesn't prevent GPG from succeeding.

But it might have prevented some random person who probably doesn't need
ciphertext encryption from wanting to use GPG if they'd realized that option
#2 was in place for them, and thus prevented this entire article's UX
nightmare at all.

~~~
nybble41
> Transport encryption and end-to-end encryption are not conflicting goals.

On that we agree. It's better to have both. Even if you already have end-to-
end encryption for the content, transport encryption helps to avoid leaking
metadata about who the message is being delivered to.

> I refuse to accept the defeatist view that "encrypted email cannot be made
> mandatory without breaking compatibility anyway".

Whether you accept it or not, if you reject unencrypted messages, or insist on
only sending encrypted messages, then you aren't interoperable with today's
email system. That's not a defeatist view, it's just being realistic. And as
we've seen with GPG, if you don't insist on encrypting everything then
encryption will not be used—or worse, it will be used inconsistently, as in
the case of someone sending an unencrypted reply which quotes an encrypted
message.

> I'm interested in protecting people who think that email should be safe in
> transit — the same expectation that postal services give them about their
> mail today — by seeing everyone who operates an email server enable
> transport encryption.

Plain email can be improved somewhat but it's still essentially the same as
writing your message on a postcard. Transport encryption is akin to physical
custody of the mail; it's useful but not sufficient. The only people who would
see your postcard while it's in transit are postal workers, and yet people
still use envelopes to keep their messages private _from the people handling
the mail_. Transport encryption does nothing to help in that area and _does
not_ fulfill the expectations that people have in regard to postal mail, which
are based in large part on legal codes and physical properties which do not
apply to email. To get something similar to a message in an envelope the
content must be encrypted end to end, not just at the transport layer.

