
Stop Using Encrypted Email - lvh
https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html
======
cipherboy
Hey 'tptacek and 'lvh. You definitely make valid points. But your arguments
here on HN could perhaps be reduced if you adequately framed the problem:

RFC 822/2822/5322 e-mail, on top of RFC 5321 SMTP and RFC 3501 IMAP, can't be
secure. (And more RFCs I'm probably forgetting).

To most people in the target audience (LARPers, technologist, and others),
"email" isn't necessarily that. It's whatever Google/Outlook/... does for
them. It isn't a concete set of protocols. But a _type_ of messaging. A
particular set of ergonomics.

When framing it from that perspective, people (programmers?) will go "well
duh". Then we can move on from the unproductive discussion about semantics and
move on to defining new standards, clarifying threat models, and building a
real replacement people and companies will adopt. It'll take a lot of
coordination and cooperation that can't happen until we've convinced enough
people what the real problem is. And as long as we're using vague, subjective
terms like "email", I don't think we can.

~~~
tptacek
Nobody is going to adopt a new email standard that lacks the problems SMTP
has. People will instead build new secure messengers that come closer and
closer to the ergonomics of email, and that's what people who see a future for
"secure email" should be looking towards, not some doomed effort to get the
Internet to migrate to a new email protocol.

~~~
cipherboy
Hmmm perhaps. But while we keep calling "email" the problem, we limit
ourselves to creating "not-email". That's an admittedly large box, but when
$politician and $businessperson is still addicted to "email" and asks for it
by name, you can argue as much as you want, but not get 100% traction. It is a
people problem. A naming problem. A publicity problem.

IMO, better to leave "email" open as a generic term, with the hopes that one
of these new messengers (hopefully, Signal) can eventually be standardized and
opened to other implementations for adoption inside $bigcorp.

But what do I know?

~~~
tptacek
I don't know what you know, but I can say that Signal and Signal Protocol have
protected so many more messages than PGP that, by comparison and to a rough
first approximation, we could say that PGP has protected effectively no
messages. Signal isn't even the most popular messenger with end-to-end
encryption, and its uptake so far outstrips that of PGP email that the two
aren't even comparable.

So appeals to the email userbase aren't especially interesting to me. My
concern is that nerds are continuously trying to convince normal people that
they _should_ be encrypting email. That's dangerous, and wrong.

~~~
shp0ngle
> I don't know what you know, but I can say that Signal and Signal Protocol
> have protected so many more messages than PGP that, by comparison and to a
> rough first approximation, we could say that PGP has protected effectively
> no messages

I can believe it about Signal protocol, since it’s implemented on Whatsapp and
Facebook Messenger. But, if you talk just about Signal proper, are you sure it
protected more messages and more people than PGP?

I see this claim fairly often, but no data to back it up

~~~
aidenn0
Anecdotally I've received e-mails from two people with S/MIME or PGP
_signatures_ and zero encrypted e-mails. There are about a dozen people in my
contact list with Signal, some of whom I exchange messages with regularly.

------
begriffs
OP has an extravagant threat model. Yeah if I were trying to hide
communications from some dictator where even the metadata of recipient and
timestamp is damning then of course email is out.

PGP is a good way to communicate under the right circumstances. Say I'm
writing to someone I trust and have verified their key fingerprint via a
secure channel (in person, over the phone, etc). If I were sending them login
credentials for a shared site, or bank info for setting up a payment, or even
just wanted to block general corporate snooping then what's wrong with PGP?
It's "pretty good privacy."

It's nice that I can apply the cryptography on a local machine and then send
the result over email. I don't need to sign up for the paranoid chat app du
jour.

( In fact PGP is useful for more than signing/encrypting mail, see
[https://begriffs.com/posts/2016-11-05-advanced-intro-
gnupg.h...](https://begriffs.com/posts/2016-11-05-advanced-intro-gnupg.html) )

~~~
bad_user
Have you read the article?

The problem isn't just the metadata leak, far from it. Some problems
mentioned:

1\. PGP is old and broken and messages can potentially be decrypted without
access to private key

2\. Because email's default is plain-text, in real world conversations you end
up with people replying in plain text with your whole message being quoted

3\. Archived messages will leak. An e2e channel needs to have a way to inform
receivers that messages should be deleted after some time

4\. Private keys eventually leak, therefore it is important that when it
happens, the system makes it hard to decrypt old messages (by combining it
with ephemeral keys).

So if you have login credentials to send to someone, if you value that info
and I assume you do, otherwise you wouldn't use PGP, then this is precisely
the use case that encrypted email is terrible for.

PGP usage is also very user unfriendly so you’re not losing anything really,.

~~~
baybal2
> 1\. PGP is old and broken and messages can potentially be decrypted without
> access to private key

GPG works.

> 2\. Because email's default is plain-text, in real world conversations you
> end up with people replying in plain text with your whole message being
> quoted

Don't quote

> 3\. Archived messages will leak. An e2e channel needs to have a way to
> inform receivers that messages should be deleted after some time

Don't archive

> 4\. Private keys eventually leak, therefore it is important that when it
> happens, the system makes it hard to decrypt old messages (by combining it
> with ephemeral keys).

Delete them before they do.

The "new wave" of encryption like on from the guy calling himself Moxi
Marlinspike is the prime definition of an unproven technology.

The screaming headline is because he wants to make noise, and get cred for his
crowd.

His argument: GnuPG — a proven, and well reviewed technology is broken because
some minor bugs were found, despite the fundamental crypto behind it still
being more sound than anything else.

He then follows to say that a fundamentally less sound, complex unproven
system, is a better alternative. And that even when the novel crypto
messengers themselves are dogged with daily minor security bugs being found.

If I met the man in person, I would've said some warm words to him.

~~~
cwyers
Your messages are only as secure as the least careful person you correspond
with.

~~~
thaumasiotes
But that's true no matter what methods you use. When you send a message, you
don't enjoy any security at all from the _recipient_. If they decide to leak
your messages, your messages will leak. If the way they decide to do it is by
being incompetent, your messages will still leak.

Look at the HackerOne reward policy for Snapchat:
[https://hackerone.com/snapchat](https://hackerone.com/snapchat)

Among many less notable findings that aren't considered security issues, you
can see that "screenshot detection avoidance" is a non-qualifying "bug". It's
not really a bug. It doesn't qualify for a reward because _your messages
cannot be secured against people who are supposed to read them_. Security
against the recipient is (or was; I don't know the current marketing) a major
marketing point for Snapchat, but it's never been something they actually
offer.

How is "your messages are only as secure as the least careful person you
correspond with" more of an argument against PGP than it is against Signal?

~~~
soraminazuki
The parent is focusing on carefulness, and not malicious intent. If being
careful requires you to be knowledgeable in computer security or cryptography,
we're never going to have a secure communication system because people aren't
going to spend years learning those things to simply talk to people. Secure
defaults matter, and not being able to configure and use GPG correctly is
hardly "incompetence."

~~~
cwyers
Exactly this. tptacek's article talks about issues like someone replying (with
the messages quoted) in cleartext by mistake, or leaking their keys. In a
messenger like Signal, there's no easy way to accidentally reply in cleartext,
and key management is handled for you so it's not possible to accidentally
send the private key instead of the public key. It's not enough for _you_ to
never do those things, you have to trust your correspondent to be capable to
do those things without error (which is different than trusting them to not
intentionally disclose).

------
Sniffnoy
I'm going to say the same thing I said last time this came up -- so what
should we use instead, then? What do we use if we want secure messaging, _but
with the (social) affordances of email_? There still doesn't seem to be any
answer to that!

No, Signal is not an acceptable answer; it replicates text messaging, not
email. In more detail:

1\. Email is potentially long-form. I sit down and type it from my computer.
Text-messaging is always short, although possibly it's a series of short
messages. A series of short emails, by contrast, is an annoyance; it's
something you try to avoid sending (even though you inevitably do when it
turns out you got something wrong). Similarly, you don't typically hold rapid-
fire conversations over email.

2\. On that point, email says, you don't need to read this immediately. I
expect a text message will be probably be read in a few minutes, and probably
replied to later that day (if there's no particular urgency). I expect an
email will be probably read in a few hours, and probably replied to in a few
days (if there's no particular urgency).

3\. It's OK to cold-email people. To text someone you need their phone number;
it's for people you know. By contrast, email addresses are things that people
frequently make public specifically so that strangers can contact them.

So what am I supposed to do for secure messaging that replicates that? The
best answer I've gotten for this so far -- other than PGP which is apparently
bad -- is "install Signal on your computer in addition to your phone and just
use it as if it's email". That's... not really a satisfactory answer. Like, I
expect a multi-page Signal message talking about everything I've been up to
for the past month to annoy its recipient, who is likely reading it on their
phone, not their computer. And I can't send someone a Signal message about a
paper they wrote that I have some comments on, not unless they're going to put
their fricking phone number on their website.

So what do I do here? The secure email replacement just doesn't seem to be
here yet.

(I'm guessing in case (3), the authors would suggest just using unencrypted
email, but what about problems (1) and (2)?)

~~~
rocqua
I was going to write the same thing, but less eloquently!

The solution seems simple. Create something much like signal, but with the
user-interface of e-mail! This addresses your points 1 and 2 perfectly. I'd
want my UI to include actual working archives. None of this 'this message will
be deleted automatically after x days'. Because e-mail is non-ephemeral
communication. Hence I want to be able to access it.

However, point 3 introduces a relevant technical difference between signal and
e-mail that affects the user experience.

Federation.

This is what makes cold e-mailing possible. It is what allows anyone who
controls a domain to start accepting e-mails at that domain without needing
permission, or any central service.

I don't have enough of the infrastructure of signal's ephemeral key pre-
sharing front of mind. But I really hope there is some way to get this to work
in a federated system. I could eventually see this replacing e-mail.

Point 3 has one more side-effect that hurts any e2e encrypted form of
communication: spam-filtering. Because content-based spam filtering
essentially requires access to the plain text. And for it to be effective, you
want to base your filtering on a large dataset. Even if you were to move
applying the spam filter to the endpoints (ignoring compute and trade-secret
issues), you still need access to plain-texts to train your spam-filter.

Sure, you could probably share any false negatives back to some aggregator to
train the spam filter. Because generally spam sent to you doesn't need to
remain confidential. However, false-positives i.e. emails that are wrongfully
marked as spam, are not things you'd want to share back to some aggregator. I
suppose MPC could be of help here, but that would 1) fix the algorithm used
and 2) have huge computational overhead.

In summary, if we can federate e2e encryption _and_ get spam-filtering to
work, we could and should replace the entire user experience of e-mail with an
e2e encrypted protocol.

~~~
loup-vaillant
> _I don 't have enough of the infrastructure of signal's ephemeral key pre-
> sharing front of mind. But I really hope there is some way to get this to
> work in a federated system._

Well, there's one major hurdle: multiple devices. Pre shared keys (and one
time keys, and ratchet keys) are generated on the user's computer. If there's
several of them, say a Wintel desktop and an Android palmtop, messages sent
with the desktop's pre-shared keys can't be decrypted by the palmtop¹.

So we need a need to synchronise those keys between the devices. The easiest
way to do it is to store the private half on the recipient's server. But then
you need to encrypt them to prevent the server from breaking forward secrecy.
The encryption key must then be shared across both desktop and palmtop. (UI
wise, it's pretty easy: connect both devices to the server, then manually type
on the new device some low-ish entropy secret the old device is displaying on
screen.)

[1] Commonly misnamed "phone"

~~~
NoGravitas
In theory, both Matrix and XMPP+OMEMO handle multiple devices. In practice,
I've found it to be less than smooth.

~~~
cyphar
Matrix has gotten much better about this. Most scenarios where device lists
get out of date are caused by the device list cache for federared homeservers
being out of date. But with synapse 1.10 (released a few weeks ago),
homeservers will refresh the device list much more aggressively in
circumstances where it's clear that the cache is old (such as receiving a new
message from a federated user on an unknown device).

------
tptacek
Sort of just generally, to word this post more simply: whenever the point is
made that encrypted email is cryptographically inferior to secure messengers,
people respond with a litany of ergonomic reasons why secure messengers aren't
viable: they don't have the right platform support, nobody wants to type on
their phones, people want decentralized platforms, nobody wants to install new
software, and on and on.

The problem with these arguments is that they have nothing to do with
security. There's simply no case that can be made that encrypted email is as
secure as a modern secure messenger. People tolerate shoddy encryption in
email because ergonomics are more important to them than security.

The problem here is that there are real people who depend on the security of
their messages who would be taking unreasonable risks in trying to get an
encrypted email workflow going. Rather than telling these people to read a GPG
tutorial or install Enigmail or whatever, we should be telling them either to
use a secure messenger, or not to put themselves at risk at all.

~~~
jolmg
> There's simply no case that can be made that encrypted email is as secure as
> a modern secure messenger.

\-- BEGIN SCRATCH THIS

Of course there is. I can send an encrypted email to anyone and be guaranteed
that only that person has access to it, even if I have to give them
instructions on how to decrypt it.

I can't do that with Whatsapp because it's closed source. I can't do that with
Signal because nobody has Signal. Everyone has email.

\-- END SCRATCH THIS

There's also the problem that messengers like Whatsapp and Signal are tied to
my phone and so to my identity. With email I can make a free, new email
account with almost any provider and send an anonymous, encrypted email from a
public Wifi with a spoofed MAC.

You can't get that level of anonymity that easily from using a phone. Every
phone provider I know will at least want to keep a record of your ID before
giving you a new SIM card.

EDIT: I concede my first argument sucked.

~~~
pavel_lishin
> _I can send an encrypted email to anyone and be guaranteed that only that
> person has access to it, even if I have to give them instructions on how to
> decrypt it._

Genuine question: how would you send me an encrypted email, and give me
instructions for how to decrypt it? I have no published public keys; you'd
have to send me a keypair that you yourself generated - how would you do that
part securely?

~~~
asimpletune
You could associate your public key with a DNS record that you control?

e.g.
[https://tools.ietf.org/html/rfc7929](https://tools.ietf.org/html/rfc7929)

~~~
jolmg
The MitM problem is not with sending the public key. They can just email it.
The MitM problem is with intercepting the instructions from person A, having
the MitM person generate them, and provide the pair to person B while
impersonating A.

~~~
dane-pgp
If you know you want to email alice@example.dk and if you trust DNSSEC, then
fetching the public key for alice@example.dk from the DNS should be at least
as secure as visiting [https://example.dk](https://example.dk) in your
browser.

(If you don't trust that Alice's email address is alice@example.dk then you
shouldn't send an email for her to that address regardless of MitM attacks.)

~~~
jcranmer
You're omitting the part that example.dk could create a fake key for
alice@example.dk, publish that, decrypt a copy for themselves, and reencrypt
it for alice@example.dk's public key.

~~~
dane-pgp
Well, I said it's at least as secure as visiting
[https://example.dk](https://example.dk) in your browser, where your attack is
equivalent to the hosting company or DNS provider generating a new TLS
certificate for that domain without the knowledge of Alice, the nominal
registrant. (The web PKI also has the problem that any CA can issue a
certificate for any domain).

~~~
jcranmer
The catch is that the primary reason to choose encrypted email is to prevent
your hosting email provider from reading your email, so the inability of
encrypted email to provide that guarantee kind of renders it worthless.

~~~
dane-pgp
Of all the attackers you could worry about, I wouldn't put your own email
hosting provider at the top of the list. MTA-STS is nice, but it's hard for an
email client to guarantee that the hop-to-hop links between itself and the
recipient's inbox are going to be protected with TLS. Passive snoops between
mail providers seem like a much more realistic threat.

Also, by putting a public key in the public DNS, it means that Alice can catch
her mail provider's DNS server giving false information about her public key,
which would come with cryptographically signed proof of which entities were
involved in that lie. Ideally there would be an equivalent to the Certificate
Transparency system for keys that are used or protected by DNSSEC.

------
rlpb
One of my suppliers sends me PGP encrypted email invoices using an automated
system. It works perfectly well for my threat model. Security vulnerabilities
in processing this may exist, but so they might in every other system; there's
no special vulnerability in email or PGP here.

I understand that this article is _for the secure human-to-human messaging use
case_. That's fine; I have no argument with this. But outside that context, it
makes no sense, yet generic claims like "encrypted email is bad" are being
made. This is too broad.

I understand that the majority of perceived demand* for encryption may be for
secure messaging. On that basis, maybe you think it's OK to disparage
encrypted email because a win in getting universal secure personal messaging
with the modern desired properties would be worth the cost. But isn't this a
strawman? Who exactly is a proponent of encrypted email for secure personal
messaging anyway? Who is using PGP for personal encrypted communications today
who is being harmed?

* Because most people don't care; it's only a minority of advocates who, rightly or wrongly, believe that everyone should.

~~~
dfabulich
> It works perfectly well for my threat model.

What threat model is this?!

(In all honesty, I don't believe you. I presume you're _paying_ those
invoices, in which case whatever attacker you have in mind can just follow the
money and monitor the metadata to learn everything they need to know about
those invoices. Or, more likely, your threat model is "nobody's seriously
gonna snoop on my payments to this supplier; I just think it's fun to play
with PGP.")

------
aquabeagle
Typical security industry contrarianism.

"Stop using that thing that mostly works as intended and is integrated into
lots of email clients and systems, and has a number of independent
implementations, and has the decentralized properties that match email."

"What should we use instead?"

" _shrug_ You can send encrypted stickers in Signal, isn't that neat?"

If you're going to advocate for everyone to stop using something that they
rely on, make sure there's a viable alternative for them to switch to first
(or throw your weight behind making/enhancing one). Otherwise you're just
telling people to stop using plastic straws and giving them shitty paper
straws in exchange. People know they're bad but the alternatives are worse _to
them_ so they stick with the bad thing.

~~~
nothrabannosir
If you consider PGP something that mostly works, and Signal the fringe
contrarian view, then we have wildly different experiences around usability,
and the relative popularity of those tools.

I couldn’t get any of my friends or family on PGP to save my life, and some of
them are programmers. I am now at a 50/50 split in volume on Signal v
WhatsApp, and most people I never even suggested it to. And they use it
correctly (because that’s the only way you can).

Seriously: how is PGP something that mostly works, and how is Signal
contrarianism? Isn’t it the other way around by now?

~~~
sergiosgc
Signal is non-federated. That, alone, is a showstopper as an email
replacement.

Open and federated protocols and services should be our target. It is hard
designing them, but if we could do that in the past, we should be able to do
so today.

~~~
nothrabannosir
Two replies about email replacement; I feel like we’re getting off track.
Signal is for secure, end to end encrypted communication. Ideally that would
be all communication, but that isn’t realistic in today’s world.

TFA merely says: if you were gonna use PGP, use Signal instead. It’s a trade
off. While we target these open and federated protocols, let’s not throw
people who actually need encryption today under the bus.

So to the question of replacing email: unless all your email is currently PGP
encrypted, you don’t need to drop your email just yet.

~~~
sergiosgc
> So to the question of replacing email: unless all your email is currently
> PGP encrypted, you don’t need to drop your email just yet.

You don't need to drop email at all. If you trade protocol openness for
encryption, you are acquiring technical debt. How long are going to do this
dance of switching between instant messenger protocols? ICQ -> AIM -> MS
Messenger -> Hangouts -> WhatsApp -> Signal -> ???.

Open protocols (open in specs and federated in access) are the only way to
stop this madness.

~~~
loudmax
IMHO, Matrix currently has the best shot at becoming the standard for the open
internet.

Those who value the freedom of choice should push for Matrix before Signal
becomes the de-facto standard and is acquired by one of the tech giants
looking to lock down control of communication.

~~~
Andrew_nenakhov
Matrix is too dependent on it's only vendor in existence, their only server in
existence has performance issues. Also, a monolith standard is hardly viable
for federated networks, where all nodes can't upgrade all at once.

~~~
feanaro
> [...], their _only server_ in existence has performance issues.

This is either misinformed or disingenuous: [https://www.hello-
matrix.net/public_servers.php](https://www.hello-
matrix.net/public_servers.php)

~~~
Andrew_nenakhov
All these server instances use the same server software, provided by the same
vendor.

~~~
feanaro
Ah, I did not realize you were referring to the software. In that case, there
is also Construct[^1]. There are other implementations in the works, though
progress is somewhat slow.

Synapse is much better with regards to resource usage these days, though. The
RSS of my instance is 355M right now and the CPU usage is hovering around
0-10% (15-min server load ~0.5).

[^1]: [https://github.com/matrix-
construct/construct](https://github.com/matrix-construct/construct)

------
t0astbread
I agree with the points made here but based on my experiences I've not yet
seen anything that could replace archaic solutions like email and SMS for me.
Here's what I've tried and why it's failed:

(Note: This is an "everything sucks" type of comment but it's solely based on
my opinion and my experiences. I'm not trying to devalue the work of the
people who made the respective solutions and I'm not trying to frame this as
general truths. I'm sure a lot of what's listed here just comes down to my
specific circumstances.)

\- Signal: Afaik it requires a smartphone (Android or iOS) and a phone number
which are two things I don't wanna be bound to. Additionally, last time I
tried it, messages got noticably delayed and I didn't recieve any
notifications. I assume this is because I don't have the Google Services
Framework installed even though I checked and Signal should (?) work without
it.

\- WhatsApp: Metadata falls rights into Facebook's hands so no thanks.

\- Matrix+Riot: Message delivery was kinda wonky and slow when I tried it.
Also it looks incredibly complex which means someone I communicate with will
inevitably screw up just as described in the article.

\- XMPP+Conversations: This actually looked like it works for a while. What
drove me away from it in the end was that file transfer didn't work for some
reason in my environment as well as push notifications for some people I
talked to. Presumably they ran a version of Android that mandates Firebase
Cloud Messaging and Conversations doesn't use that. We did not want to delve
into debugging this further.

\- other (mostly "decentralized web") solutions: Message delivery was either
unreliable, slow or it straight up didn't work. (No hate on the dweb though.)

Email is kinda bad but so is everything else. What kind of solutions do y'all
use and why? Is there some "promised land" I've missed?

~~~
samatman
I send an SMS every few months, the vast majority of my messaging happens
through Signal or iMessage.

And yeah, Signal isn't exceptionally reliable, I've had messages go missing
for hours and even days. I hope it gets better, I'm willing to put up with it
for security's sake.

I'm not sure I understand what SMS can do that Signal can't, the difference
can't possibly be that Signal requires a phone number, can it? And SMS does
nothing to indicate delivery and used to lose my messages all the time back
when I relied on it.

~~~
samatman
Oh, right, Keybase. How did I forget Keybase?

Don't use it as much as the others because of network effects, but it works
just fine. Requires a user account but no phone number.

~~~
t0astbread
Keybase might be worth a look. The only complaint I have is that there seems
to be no way to self-host it (which is an option I'd like to have.) And the
server source seems to be hidden from public which is not great for trust.

The network effect doesn't really concern me. For communication with strangers
I'll have to fall back to email anyways since WhatsApp is virtually the only
thing that has presence in my area.

~~~
samatman
It's true that as things stand you're pretty much stuck with Keybase the
company.

But they're going to some lengths to make sure it doesn't stay that way:

[https://keybase.io/docs/client/client_architecture](https://keybase.io/docs/client/client_architecture)

I'm bullish on Keybase, even after the obnoxious Stellar Lumen airdrop fiasco.
It seems like they're doing most things right.

------
Klonoar
Y'know, you can have all the valid points in the world and still come on a
_bit_ too strong.

I get the point the author is making re: LARPing, but this kind of attitude
and tone is bordering (or, bluntly: is) condescending to anyone who doesn't
know as much as you. It's a huge shame because the general discussions
surrounding privacy/security are absolutely rampant with paranoid bullshit,
and stuff like this just doesn't help. The people you consider to be LARPing
might honestly just be new to the idea of security/privacy/encryption/(insert
your label here) and would be better served by a tone where you're not talking
down to them, especially if you're an established authority.

Personally speaking, I use encrypted email for my personal account - but I'm
under no big illusions about it, and at this point it's partly out of laziness
as I find moving email providers to be a useless exercise in wasting time. My
original use case was my wife and I wanting to send documents back and forth
easily, have it encrypted and retained somewhere that's (relatively) easily
searchable, and isn't one of the bigger email services. Email is a workflow
that goes back decades, and I'm not particularly interested in changing that
mental mapping in my brain (a feeling I suspect many would echo).

It's email. It's not encrypted or 100% private if I email my buddy who's using
Gmail/etc. It does jack all for my bills, newsletters, and so on. I'm not
worried about the metadata not being encrypted because if I needed that level
of security, I'd use Signal or some other tool.

You're probably right that it can't be "fixed", but there's also nothing wrong
with attempting marginal improvements until an eventual replacement comes
along. It remains a convenient "it just fucking works" and until something
replaces that, and interoperates with the rest of the way the world actually
works, it's probably not changing.

My 2c, at least.

~~~
tptacek
We are condescending† somewhat deliberately. It's time to start shaking
proponents of encrypted mail by the shoulders. We need analyses that spell out
the concerns starkly and don't equivocate, because the issues themselves are
stark, and a nuanced discussion (if one exists) cannot be effectively
communicated to ordinary nonspecialist users.

In a world where encrypted email was popular and no reasonable alternatives
existed, the equation would be different. But modern secure messengers have
lapped PGP and S/MIME a practically uncountable number of times. I don't know
what large power of ten the multiple is of messages protected by Signal
Protocol compared to PGP, but I do know that it's large. The risk is not that
people will naturally gravitate towards encrypted email (which is in practice
a nightmare to use), but that well-meaning but poorly-informed technologists
will try to talk them into doing that and adding encrypted email to the basket
of tools ordinary people use. That can't be allowed to happen.

I also want the analysis to be somewhat bracing for technologists. I'm not
making fun of PGP users when I say they're LARPing. I'm describing reality
directly and meaningfully. I don't think proponents of encrypted email have
really thought through _why_ they're using PGP and S/MIME, and _why_ they're
not terrified of metadata collection and the occasional plaintext reply. Their
risk profile is not the risk profile of the public at large; when you're
LARPing, it doesn't matter if you get hit on the head with the sword.

† _Not the term I would choose, but let 's stipulate_.

~~~
j88439h84
I use Signal on my phone, and I like it for the common situation where I'm
close enough with the person to share my personal phone number.

I'm still looking for a solution for the situation when I'm trying to
communicate without revealing my identity to the person I'm talking with.
Signal's reliance on phone numbers means I'd need to get a bunch of burner
phones or something, which is beyond what I'm willing to do: I'm not talking
about an ultra-high-risk situation, just I'd rather not announce who I am when
I'm interacting with people I don't know that well.

What do you think is the most promising tool for this sort of communication?
I've been hearing about Riot/Matrix; do you think that's a good option for
people to use?

~~~
thayne
For a specific, common usecase, what should be used for submitting security
bugs for software?

Another concern I have with the proposed replacments is many (Signal, Keybase,
etc.) depend on a single centralized service.

~~~
anchpop
The idea with Keybase (can't speak for signal) is that your client doesn't
need to trust the server. You only need to trust that your client isn't
compromised, which is easier to verify.

~~~
thayne
Sure (and that's true for signal as well), that's not my point. My point is
you have to rely on that service being available. And you need to trust it to
deliver and (at least with keybase) persist your encrypted data. And if that
service becomes as prevalent as email, that gives the organization that
controls it a lot of power.

------
upofadown
What's with all these articles dissing the very idea of encrypting email? It
used to be that hardly anyone cared. Now there seems to be some effort to
discourage something that any reasonable person interested in privacy would
enthusiastically support.

This is a pretty typical example from the article of the sort of important
sounding but ultimately bogus argument presented in such articles:

>So, for example, it recently turned out to be possible for eavesdroppers to
decrypt messages without a key, simply by tampering with encrypted messages.

By failing to actually specify the actual attack the writer hopes to prevent a
rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a
weird slander of the idea of encrypted email but ultimately did not show any
weakness of either PGP or S/MIME. It was instead a cautionary tale about the
use of HTML for email.

The article attempts to promote Signal as superior to PGP email. That is
unlikely as Signal initially trusts the phone system for identity. It is also
quite a lot more complex than PGP so the odds of an exploit are not in
Signal's favour.

~~~
mkhpalm
> By failing to actually specify the actual attack the writer hopes to prevent
> a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself
> a weird slander of the idea of encrypted email but ultimately did not show
> any weakness of either PGP or S/MIME. It was instead a cautionary tale about
> the use of HTML for email.

What you said there can't be stressed enough. Despite that almost no email
client in the past decades defaults to allowing active or remote content. But
because you could turn all that on with _some_ clients... it somehow means PGP
and S/MIME were impossibly insecure.

"Weird" is a good word to describe things.

~~~
cyphar
Efail worked with the default settings on almost all clients except Mutt. Most
email clients do not have a "plain text" mode. They all display emails as HTML
and apply some formatting to make the "plain text" mode be monospaced.

Also, one of the Efail exploits (the CDC gadget) _was_ a cryptographic
vulnerability. The fact you could manipulate the ciphertext to inject HTML
tags such that GPG wouldn't scream bloody murder (because the MDC wasn't
required and had very odd semantics, where GPG would output data to the caller
before it had been authenticated and clients showed it as a warning and still
rendered the HTML exploit) was definitely at its core a cryptographic bug.

All of this was explained in significant detail in the CCC talk about
Efail[1].

[1]: [https://media.ccc.de/v/35c3-9463-attacking_end-to-
end_email_...](https://media.ccc.de/v/35c3-9463-attacking_end-to-
end_email_encryption)

------
koevet
I understand the points of the article and somehow agree with them.

But I still think that PGP can and should be used in certain scenarios: think
of how Snowden interacted initially with Glenn Greenwald and Laura Poitras.

That particular scenario was about anonimity (I don't want to reveal the
sender persona just yet) and temporary "validity" of the messages: if down the
line, one or two years later, the message gets decrypted, no harm is done.

Potentially, Snowden could have used a burner phone, install signal and get
hold of the journalists phone number - more difficult that email, but not
impossible. In Europe it's not so simple to get a sim card in a complete anon
way: not impossible, but if one need several sim cards it may get cumbersome
and expensive.

~~~
NoGravitas
Today, you would use SecureDrop[1] for that particular use case (talking to
journalists with an established organization). But you're still right for the
general case.

[1]: [https://securedrop.org/](https://securedrop.org/)

------
paxys
Agree with pretty much everything in the article. Encryption is not a property
of email, and will never be. And if you manage to add a perfect encryption
solution on top, it stops being email.

The most that can be done at this point is to build a new closed "email v2"
which cannot interoperate with any existing client out there, but because of
that it will inevitably be dead at launch.

~~~
wmf
I could imagine Signal Desktop adding a mail-like UI that still interops with
Signal.

~~~
tptacek
Something like that will eventually happen, because lots of people want a good
desktop mail-like experience for secure messaging. And there's nothing wrong
with that, as long as the backplane for such a system isn't SMTP email.

It's not the core email UX that's the problem; it's SMTP email that's the
problem.

~~~
jackpirate
_It 's not the core email UX that's the problem; it's SMTP email that's the
problem._

You're article seems to argue the opposite to me. For example, the following
quotes are all related to the email UX:

1\. _In any group of people exchanging encrypted emails, someone will
eventually manage to reply in plaintext, usually with a quoted copy of the
entire chain of email attached._

2\. _Every archived message will eventually leak._

My understanding is that it would be possible to create an alternative app
that is compatible with the Signal protocol that would provide a different UX.
This alternative UX could, for example, offer the ability to save all messages
onto google docs, eliminating the benefits of secure messaging.

~~~
tptacek
There is nothing about the core UX of email that requires plaintext as an
option; you can straightforwardly imagine, and probably even readily
implement, a secure messenger with the same UX as Outlook in which it's not
possible to plaintext-reply a message, or send plaintext at all.

Archival is a problem. But you can also imagine something with the UX of
Outlook that implements the same advisory-level disappearing messenger feature
that modern secure messengers have; in fact, I wouldn't be surprised if you
told me Outlook already has that feature (but that it only works for Outlook
users).

The problem is the legacy of SMTP. It's not what the UI looks like.

~~~
TylerE
Pretty hard to block PrintScreen though.

~~~
lvh
Sure! But a screenshot is trivial to forge anyway, and even if you block
PrScrn, people can always taddle. The goal is to get the message safely to the
recipient, not prevent the recipient from disclosing anything afterwards.
(Non-repudiation is a common goal, but screenshots being easy to forge solves
that.)

------
tobias2014
I'm surprised no one has mentioned Delta Chat yet. It solves some of the
problems, as it's based on email but adds automatic encryption. See
[https://delta.chat/](https://delta.chat/) and
[https://autocrypt.org/](https://autocrypt.org/)

For me this is a good compromise and a great alternative to messengers like
Whatsapp and Telegram. This is a first step towards decentralization while
relying on the existing email infrastructure.

~~~
spindle
And Delta Chat encrypts not only messages but also metadata, right?

Although only when used properly - again, there's no point in relying on Delta
Chat if your correspondent is going to forward your messages to people on
gmail.

~~~
aidenn0
[https://github.com/deltachat/deltachat-core-
rust/issues/1032](https://github.com/deltachat/deltachat-core-
rust/issues/1032) implies that the most important metadata (who sent and who
received the message) is not encrypted.

~~~
tuuxi
well, at least the issue says, they can be removed from the easily visible
header, so they could also be encrypted.

but smtp will know anyway.

i think, this is a general issue with "who is messaging whom" \- also signal,
whatsapp, whatever have to deliver the message and cannot know this afaik when
these delivery data are end-to-end-encrypted. so this is not only an email
problem.

but with email, at least, there is no "global" server that sees everyhing (no,
also not gmail outside us :) and can draw a huge social graph.

------
dooglius
Email+PGP may have some usability flaws, but it far surpasses the security of
Signal against powerful adversaries, especially concerning metadata. Signal
leaks your phone number which can easily be traced back to your physical
location and identity, while email+PGP can be used over Tor or a similar
anonymization network.

~~~
lvh
Can you describe how Signal leaks your phone number and what capabilities and
adversary needs to get it? (I know the answer, I am asking rhetorically,
because I don’t think that someone who knows the answer would make that case.)

~~~
dooglius
An adversary could compromise the signal server and observe how messages are
routed. Applying pressure or coercion to achieve this is well within the
capabilities and willingness of state-level adversaries. An adversary could
also compromise the person you are communicating with, not to mention cases
where you don't want to leak your physical identity to a someone you are
messaging.

------
tialaramex
Somebody has had a really bad weekend in a muddy field apparently. Also real
LARPers don't want sharp swords, the whole point is that it's not actually
dangerous - no edges, no points, nobody is supposed to get actually hurt.

I'm more optimistic than this blog post allows for. I see email's trajectory
over my lifetime and it looks like incremental improvements really do work,
they just aren't fast. And I think just as Signal lacks an "Encrypt" button
because that's the wrong UX (everything is always encrypted, no need for a
button) that's email's future too. You aren't going to install "Really good
privacy" and have encrypted email. Just one day perhaps many years from now
you'll be debugging a weird problem and you'll discover that without ever
noticing it your email is actually encrypted end-to-end and you're not
actually sure when then started happening or how.

~~~
tptacek
Candidly: I've never LARPed or even watched anyone LARP. I just assume they're
swinging foam swords at each other's tin-foil armor. That's as sophisticated
as the analysis behind my choice of words is.

~~~
pvg
Surely you've seen the lighting bolt, lightning bolt meme video. It's implied
in making dumb LARP jokes!

~~~
tptacek
I have not! Whose sentences are you calling "jokes" and whose jokes are you
calling "dumb"?

~~~
pvg
Strictly in the Pickwickian sense, of course.

Anyway, this is it. Its stratigraphy is in the layer above All Your Base but
below Leeroy Jenkins. An important, if transitional fossil.

[https://www.youtube.com/watch?v=j_ekugPKqFw](https://www.youtube.com/watch?v=j_ekugPKqFw)

~~~
tptacek
Well, that's definitely the image I was trying to evoke.

------
_bxg1
Good points, but the adversary for my encrypted email is corporations casually
collecting data, not nation-states targeting me. Plus, most of these are one-
way notifications coming to me, not threads. For my case, ProtonMail works
fine.

------
eximius
Okay, so what would a secure email alternative look like?

Can we design a system such that sending a message from alice@foo.com to
bob@bar.com is reasonably secure and private? How does Signal/NOISE solve
this? Why can those not be applied to non-messaging systems (or, at least more
traditionally structured messaging systems - which is itself a questionable
definition since email threads are a hack, its mostly just independent blobs)?

I guess I'm off to read the whitepapers for NOISE and Signal tonight to see
how the models differs.

~~~
derekp7
I would love to see a protocol added, so that when alice composes an email a
request is sent to bob@bar.com with a special header to retrieve bob's private
key. This in turn would be signed with a cert from bar.com, which in turn is
signed by one of the same trusted CA's used for HTTPS traffic.

Is there anything like this currently implemented / standardized?

~~~
WorldMaker
ActivityPub will bootstrap public keys from WebFinger (over TLS/HTTPS).

Keybase has an even more complicated key escrow-based system (that works for
any of their "Proof" types, not just domain ownership) if you trust their
clients, where your client generates an ad hoc key for the recipient and
essentially a "for bob's ears only" claim and on verifiable Proof from Bob
securely exchanges the ad hoc key to Bob's new public key. Which is
interesting because it allows for people that haven't yet setup keys to
eventually receive them so long as you trust Keybase's clients and their Proof
infrastructure.

------
sixstringtheory
I really want to use Signal but having a centralized server and requiring my
phone number turn me off. I'd love to be able to self-build the iOS [0] and
desktop [1] apps, and self-host the server [2]. Has anyone tried any of that,
are any of them even possible?

[0]: [https://github.com/signalapp/Signal-
iOS](https://github.com/signalapp/Signal-iOS)

[1]: [https://github.com/signalapp/Signal-
Desktop](https://github.com/signalapp/Signal-Desktop)

[2]: [https://github.com/signalapp/Signal-
Server](https://github.com/signalapp/Signal-Server)

~~~
balladeer
On iOS you'd have to constantly redo it via TestFlight or Jailbreak. You could
build and install on Android. But "your" binaries won't connect to Signal
servers.

Yes, you can host your own _Signal server and have your own singed apps but it
will have to be your own _Signal network, not Moxie/Signal Foundation's
Signal. Search around. Here's one -
[https://gist.github.com/aqnouch/9a371af0614f4fe706a951c2b976...](https://gist.github.com/aqnouch/9a371af0614f4fe706a951c2b97651e7).

Some context:

[https://github.com/signalapp/Signal-
Android/issues/282#issue...](https://github.com/signalapp/Signal-
Android/issues/282#issuecomment-21763403)

[https://github.com/signalapp/Signal-
Android/issues/127#issue...](https://github.com/signalapp/Signal-
Android/issues/127#issuecomment-13335689)

[https://github.com/LibreSignal/LibreSignal/issues/37#issueco...](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165)

~~~
gnomewascool
> Yes, you can host your own _Signal server and have your own singed apps but
> it will have to be your own _Signal network, not Moxie/Signal Foundation's
> Signal.

I don't think that's quite true. You might[0] be discouraged from running your
own self-built binaries, but given that Signal Android has reproducible
builds[1], I don't think that there's any actual technical barrier. The
context of your links is about having (unofficial) third-party packages for
Signal, not about somebody building the binary for their own use, and since
these are obviously two different things, from a _social_ perspective, I don't
think that the Signal foundation would complain much about the latter (given
reproducible builds and the fact that you wouldn't be distributing the
binaries, they probably wouldn't even know about it).

For Signal-iOS, it seems that you won't get push-notifications if you build by
yourself.[2]

[0] I'm not 100 % convinced that "We would not recommend that anyone use an
unofficial binary build" was meant to refer to building for yourself, by
yourself.

[1] [https://github.com/signalapp/Signal-
Android/blob/master/Repr...](https://github.com/signalapp/Signal-
Android/blob/master/ReproducibleBuilds.md)

[2] [https://github.com/signalapp/Signal-
iOS/blob/master/BUILDING...](https://github.com/signalapp/Signal-
iOS/blob/master/BUILDING.md)

------
dathinab
As a side note any messenger relining on the phone number is to some degree
fundamental flawed, too.

No idea why many recent secure messenger thing using the phone number for
anything is a good idea. You don't need the phone number to have locally
stored contacts.

Also how trustable your local Google/Samsung/... provided address book is is
another question (I'm not saying Google/... is hacking you but they probably
would love to collect statistics about your contact book and sell them, at
least if you, maybe accidentally, allow syncing of your contacts with your
Google account. Does anyone here know if their terms of service would allow
that?)

------
jolmg
> encrypted email is LARP security

LARP here is a link to Google and from the results I can only assume that it
expands to "Live Action Role-Playing (Game)". I don't get how that's related.
What is "Live Action Role-Playing Security"?

> most people who encrypt emails are LARPing

They're role-playing what?

~~~
johngalt
Just replace it with 'pretending'.

LARP Security = Pretend Security

LARPing has a connotation of nerds ineffectually playing pretend warrors.
Going through an immense amount of effort in the process.

------
david_draco
The post would be better if it clarified what threat model they have in mind.

For tampering, PGP-signed email is helpful.

For protecting secret communication contents, PGP-encrypted email can be
helpful to some degree.

For preventing a surveillance from knowing who you talk to, when, from where
and what type of content you likely exchange, email cannot become secure.

I suspect it is the combination of the three the author has in mind.

------
vorpalhex
Want to send a truly secure message? Write it out by hand in a concrete
enclosed room and then set it on fire. Boom. No interception. I mean, of
course, that's not a very useful message - but it's extremely secure!

It's kind of like the ideal way of securing a computer - encase it in concrete
and drop it in the marianas trench. A volcano would probably work too in a
pinch.

The issue that some security folk, such as the author, don't comprehend is
that people want to actually _use_ their tools and maybe, just possibly, have
a decent experience in doing so.

Sure, encrypted email isn't perfect. It's probably a step better than letting
Google scan _every_ email and instead only let them scan the ones that hit a
gmail account. Likewise, two people are capable of having a reasonably secure
conversation over encrypted email.

Calling people who move towards being more secure, even imperfectly, as
LARPers is rather insulting. If anything, the author is LARPing as a security
professional.

------
lmm
Fine, I'll bite.

A phone number is far more identifying than 10+ years' worth of email
metadata. Anonymous email is still possible (if difficult); anonymous phone
numbers largely are not. And if your adversaries are state-level then your
phone number gives them not only your name and address, but also a direct and
easy way to track your location in realtime.

OpenPGP's key rotation remains the closest thing to a practical approach that
actually exists. No supposedly "secure" messenger has managed to do better:
either your contacts' keys sometimes change for reasons that you don't
understand and you occasionally get told to "press OK to continue", or they
don't change at all. That is not a sustainable approach for real security.

As the article points out, snake-oil encryption products are everywhere. How
can you be sure you're not using one? Because tptacek posted saying this one
is secure? At a minimum the product needs to be an open-source implementation
of a published, established, reviewed standard with multiple independent
implementations. Especially any random number generator it uses needs to be
open-source, as that is the easiest way to backdoor an encryption product. And
the way its cryptosystem provides security - the algorithms that it uses, the
assumptions they rely on, the model and reasoning that turns those into
guarantees - need to be simple enough that you can understand them, not rely
on vague handwaves like "the proprietary intermediary server can't do anything
except during the initial handshake, or if the client ends up redoing the
initial handshake, but don't worry about what circumstances might cause that
to happen".

Signal is unsafe and cannot be made safe. Stop using Signal.

(If you want something more constructive, work on better UI to make OpenPGP
key rotation easier (using subkeys, they're right there in the protocol),
better implementations of OpenPGP (i.e. more usable libraries), or non-email
OpenPGP messengers to avoid the metadata issues)

~~~
RedComet
Maybe you didn't get the memo, but you're not allowed to criticize Signal
anymore. And any time it's mentioned you have to draw phony comparisons
between it and something that is on the naughty list (PGP as of late).

------
leni536
You want signal to replace email?

1\. Federate it.

2\. Don't tie it to phones/phone numbers.

~~~
puzzlingcaptcha
Oh, so you mean like XMPP?

~~~
steerablesafe
Why did we ditch XMPP again?

~~~
puzzlingcaptcha
I often wonder. I still run my own server for a small group of friends.

------
rdiddly
Sounds like security absolutism again. Encrypted email, even using a weak
algorithm, is more secure than unencrypted email and will deter some
percentage of attackers.

Yes, PGP is weak, metadata is exposed, email wasn't designed for any of this,
and people will fuck it up.

It tickles me that plaintext replies are submitted as an argument against
encrypted email. The reply being in plaintext is an example of _UN_ encrypted
email. If you oppose a thing, let it be because of what it is, not its
opposite. You don't sell your failed useless car because of that one time it
broke down and you had to take the bus. Hopefully in my view, you sell it
because of what it does when it _works_ \- it burns money, stinks, is loud,
and kills people. (Car hater here, so I personally know the difference with
this particular analogy.)

Actually to me "encrypted email" isn't even a thing. There's encryption and
then there's email. If you have a secret, you encrypt it, and if you're OK
with sending it publicly (i.e. via email) then you _attach_ this encrypted
secret thing to the email. And get the key to the person somehow privately. I
dunno what the big deal is. No matter how earnestly and ferociously you
declare yourself the mom and dad of the world, they all still keep messing up,
murdering each other etc. and nobody cares, so take a vacation.

------
acd10j
As someone who has very crude high level understanding of encryption, I think
this post has opened my eyes, I always used to think that End-to-end Secure
email is possible, just not widely available right now due to lack of support,
and they will get picked up as with wide company support like when Gmail will
adopt them. Now I know that it is futile to build them, May be some email
alternative from Signal or Matrix will be better. All points made by OP makes
total sense.

------
MikeGale
The article comes on so strong that many will be inclined not to believe it.

One point. The encrypted systems are many and not inter-operable. That's a
problem for me and many others.

------
owaty
I don't see a single argument in the article why, conditional on:

1\. Me deciding to send a given message

2\. Me deciding to use email for that message

... I should send it over an unencrypted email rather than encrypted one.

I see arguments for using other systems like Signal. I see arguments for a
false sense of security — i.e. if I didn't assume the email was secure, I'd
write a different message.

But, again, for a given message being sent over an email, I just don't see any
reason not to encrypt it if it provides at least some protection (and saying
it doesn't would probably be too much hyperbole even for latacora). The
authors sort of just declare out of nowhere:

> But email cannot promise security, and so shouldn’t pretend to offer it.

And if "pretending" meant rot13, I would agree. But even despite all its
flaws, there's a sea of difference between rot13 and PGP. If I can publish the
encrypted contents of my email publicly, and not even tptacek can decrypt it,
then it's not pretending.

So, what is the downside of encrypting an email compared to not encrypting it?
I can't think of any, and apparently the authors can't either, despite trying
very hard.

------
Nasrudith
Am I missing something? I thought the PGP vulnerability wasn't in the
Cryptography but the mail client rendering the HTML like a browser and
allowing it to be outgoing. Still a dumb move but fixable via going plain text
everything.

Granted the metadata and backlog issuss are themselves serious issues for the
format.

It is more a "stop using email even if encrypted" than "stop encrypting
email".

~~~
tptacek
This claim about Efail is essentially false. Efail was possible because PGP
uses an archaic message authentication scheme, one designed more or less
before the dawn of authenticated encryption, which can be stripped off
messages, and which is in a real sense an "add-on" as far as the core of PGP
is concerned. PGP will release unauthenticated plaintext to its callers and
count on them to check out-of-band errors to see that the plaintext isn't
safe; mailers failed to reliably perform this check.

There is a technical sense in which mailers are responsible for mitigating
this vulnerability, but it's a vulnerability that can't exist in the first
place in a well-designed cryptosystem.

In the context of this post, this is basically a nit; the point the post makes
is that even if you replace PGP with something like Age, encrypted email is
still too risky to use, and is intrinsically inferior to modern secure
messengers. (Encrypted email is not a use case Age is pursuing, and I do like
Age).

~~~
upofadown
Claiming that EFAIL somehow showed a weakness on the part of PGP and S/MIME is
like saying that a caretaker that lets burglars into their tenant's apartment
is an example of bad lock design. Sure the lock maker could of removed the
ability to use a master key but that is simply not a reasonable thing to
suggest.

~~~
tptacek
I can't follow this analogy. Claiming that Efail showed weakness on the part
of PGP is like claiming that cryptosystems should be designed not to release
unauthenticated plaintext to callers, and that the
"authenticated/unauthenticated" status of a message shouldn't be communicated
out of band. You know, like how all modern AEAD cryptography works.

------
parliament32
>If messages can be sent in plaintext, they will be sent in plaintext.

I don't buy that argument. There's definitely ways to fix this, and the best
example right now is Signal.

I use Signal as my SMS app as well. This gives me a single interface for all
my messages: For contacts without Signal, messages get exchanged as SMS. But
for contacts with Signal, the conversations become end-to-end encrypted
automatically. There are UI hints (Signal conversations have padlocks beside
messages and a blue send button, vs a grey one) but overall it's seamless and
transparent.

This is totally possible with email too: look up if the receiving end has a
PGP key published (PKA[1], SKS[2]) and auto-encrypt if they do. It'd be nice
if we had an email client that did this.

[1] [https://keyserver.mattrude.com/guides/public-key-
association...](https://keyserver.mattrude.com/guides/public-key-association/)

[2] [https://sks-keyservers.net/](https://sks-keyservers.net/)

------
zach_garwood
> Ordinary people don’t exchange email messages that any powerful adversary
> would bother to read, and for those people, encrypted email is LARP
> security.

Point of order: Can we go back to using adult words like "performative" or
"artificial" or "mimicry" etc, instead of accusing everyone of being a LARPer?
It really just smacks of an immature 4chan insult.

------
cyphar
> There are, of course, web email services that purport to encrypt messages.
> But they store encryption keys (or code and data sufficient to derive them).

While I assume they are talking about things like Protonmail here, there is a
case where PGP is better than nothing here. Mailbox.org allows you to provide
a PGP public key which they will encrypt all incoming messages to. I have Mutt
configured to auto-encrypt emails saved in my sent folder.

Now, obviously this doesn't help if Mailbox.org becomes malicious or gets
attacked. But it does protect my personal email archive. If someone managed to
access my email account, they couldn't read any old emails (but they could
disable it for new emails).

Maybe I'm LARPing and I don't know it, but I think it's a neat feature which
is worth more than nothing. But I do agree with the rest of the points the
article makes -- though I think Matrix is a better secure messaging
replacement than Signal because it's federated -- especially now that it has
E2EE by default.

------
parasense
I read this more as a condemnation of email itself, and less about PGP.

PGP aligning with how email actually works and the author not liking the
effects is a pity, but by comparison it's a whole other dichotomy from
something like a mediated end-to-end crypto scheme. Those kind of systems have
the exact oppose set of problems from PGP conceptually, and note this ignores
the geriatric architecture of PGP to some extent.

Assuming PGP were re-invented right now, I'd still like it to mostly stay the
same. That is to say, I'd like to be able to have private/public keys stored
in something conceptually similar. I'd like to see slight ease-of-use
improvement in signing objects, encrypting objects, etc... but the basic
functionally be the same. Finally I'd like to see integration with other
transports made more modular and around an API versioning system that moves
forward. That is to say, If I sign my emails, I'd like to be able to
communicate that the other end should be on an API above some level, or
similar setup.

Finally, there would bee some more thought put into people who want to
advertise their keys on public directories. The aforementioned API versioning
and modular remarks head into this direction. People want to communicate their
keys, and it should be easy for social networks, or whatever directory lookup
providers that would be created can be accommodated. This is key

People like things like the signal protocol, but they want to manage all the
stuff in the middle themselves, or whatever that entails. Some people may want
to fly bellow the radar, and not have anything to do with an automated system,
or run sneaker-nets like some old school cloak-and-dagger stuff from KGB or
CIA.

Anyways, email is terrible. But to conflate the problems of email over to PGP
is a bit weird, but it's nice to recognize the real issue of using both.

~~~
lvh
We’ve written both versions of that argument: PGP and email. This one focuses
on problems that a better GPG could not fix. (Discounting my own “pathological
examples” from a different thread.)

------
scelerat
There's a lot of evidence of careless skimming in the comments here. The
article didn't say "don't use email." It said "don't use email for encrypted
communication." Because it can not and will never meet the minimum standards
for such. Keep using email! Just not for sensitive/secret/confidential
communication

------
3pt14159
Here's my counter example:

[https://github.com/zachaysan/toolies/blob/master/wallet.dat....](https://github.com/zachaysan/toolies/blob/master/wallet.dat.gpg)

That's my original wallet from 2011 that I uploaded to GitHub a couple years
later when the amount of money it had in it became non-trivial. GPG works
great[0]. I emptied the wallet near the top of the last Bitcoin run up, but
honestly even if I still had money in there I wouldn't worry about commenting
about how it's public.

As for the rest of it, he's right about metadata and right about human
failures like following up with plaintext responses. But on the other hand if
your email box leaks then at least most actors are not going to be able to
break encrypted messages, which are arguably the most important.

[0] And yes I know the difference between symmetric / asymmetric encryption,
but I'd trust it if I'd done it with keys too.

~~~
obituary_latte
404? GitHub link seems broken...

~~~
3pt14159
Sorry for the late reply, apparently I made the repo private after putting in
some aliases in my bashrc file that would have leaked information I didn't
want to leak.

But it had nothing to do with the wallet file. That thing was public for
years.

------
goffi
While we are at suggesting encrypted IM, I'm wondering something: I'm not
using Whatsapp or Signal, but I have the feeling that for UX reason the users
never have to validate a fingerprint (or QR code or anything similar). How is
this working? They are using TOFU right (there will be a notice if the
fingerprint change)? What happens if a user gets a new device? Can anybody
with experience with those apps explains how it works?

Because e2ee doesn't really makes sense without proper authentication (we're
talking about protecting against malicious server, right? So what happens if a
server add a fake device or change fingerprint).

Conversations use Blind Trust Before Verification, that means that until a
first fingerprint is checked, everything is accepted, so e2ee only protect
against server archive/passive attacks, but not again an actually malicious
server.

note: I'm a XMPP dev and I'm wondering how it's done in other apps as a point
of comparison.

~~~
upofadown
Signal basically trusts on first connection where you trust the Signal company
to do something with an SMS to link your identity with your phone number.
After that you have a fingerprint (they call it a "safety number") if you want
to check to see if you are still talking to the same entity. It will warn you
if the number changes.

So how different that is from Conversations depends on how much you trust the
Signal company and the phone company. In either case you really have to check
the fingerprint, just like with everything. The issue is inherent to secure
communications and can not be avoided with any sort of improved user
interface.

~~~
goffi
I see, so you can verify but it's not by default. What happens if you add a
new device (e.g. a tablet so a new fingerprint, which is different from
changing main device where the original fingerprint changes)? Is the new
fingerprint accepted without user validation?

My point is that e2ee makes sense when you don't trust the server (here Signal
company, or FB for whatsapp), so if most people don't check the fingerprints
(and I assume it's the case), what's the real value of it?

~~~
lvh
This is a core difference between Signal and eg WhatsApp. The Signal UX
clearly shows who’s verified, and the UX clearly earns you when the safety
number changes. Additionally, the secondary device model (eg Signal Desktop)
goes to great lengths not to break that. With WhatsApp, you’re trusting
WhatsApp.

------
einpoklum
The author is presenting a binary view of email security.

It's true that email as a protocol has inherent insecurities ; and it's also
true that dedicated, rich spies are probably able to exploit many of them even
with encrypted message bodies.

But most of us are facing the problem of __MASS SURVEILLANCE __, which
statistically is more serious.

So:

1\. Stop using spied-upon email servers:

1.1 Drop your Gmail, Yahoo mail, Microsoft etc. mail accounts, in favor of
non-US and/or non-huge-corporation mail service providers.

1.2 Try to get your friends and family to drop theirs. Yes, I know this is
extremely hard...

1.3 Try to get your workplace / NGOs you volunteer in to drop use of those
servers (and also of Google Apps, Office 365, Skype etc. which have strong
tie-ins with the email services).

2\. Use mail clients which auto-encrypt messages to recipients with known keys
- like EnigMail for Thunderbird.

The more of that is normalized, the harder

~~~
lvh
If you're going to do 1.2 and 1.3 and get everyone to make massive changes to
how they operate, why not just use a secure messenger instead of trying to
shoehorn privacy onto a protocol designed for when the Internet had like five
computers on it and all the people knew each other?

~~~
einpoklum
Because email and secure messaging are not the same thing, and the latter does
not replace the former. Now, there could be a distributed infrastructure for
"email" that's not SMTP-and-IMAP/POP3-based, theoretically, based on what is
now used for secure instant messaging - but I can't just recommend this to
individuals.

Also, my suggestions do not make email private, they reduce the exposure to
large-scale surveillance and make it more difficult to target individuals.
Also, they do not involve "shoehorning" as far as user experience is
concerned.

~~~
cjbprime
> But most of us are facing the problem of MASS SURVEILLANCE

All that you're accomplishing by switching to decentralized servers is
publishing the metadata that you claim to be concerned about for free. Before,
someone had to serve Google a valid subpoena to find out who you've been
talking to. After, you're just broadcasting it publicly across the net in
network header logs.

~~~
einpoklum
You're misinforming people. Nobody has to hand Google anything. The NSA has
direct access to their systems and can take in as much as they want.

This is not a conspiracy theory - it is public knowledge thanks to the Edward
Snowden leaks.

~~~
joshuamorton
Can you cite that this is true today?

~~~
einpoklum
Seriously? :-(

~~~
joshuamorton
Yes, as far as I can tell you're claiming one of three things

1\. Google actively assisted the NSA with data collection, beyond legal
obligations (subpoenas etc.)

2\. The NSA had a way of legally compelling companies to provide direct access
to systems and can do arbitrary processing on company internal data

3\. The NSA was snooping in Google's systems without Google's knowledge in
2013, and this hasn't been fixed 7 years later.

As far as I know, the Snowden leaks don't provide any real evidence for (1) or
(2), and so are an extraordinary claim without evidence. (3) also seems rather
unlikely. Hence the question.

~~~
cjbprime
I think OP is talking about
[https://en.wikipedia.org/wiki/PRISM_(surveillance_program)](https://en.wikipedia.org/wiki/PRISM_\(surveillance_program\)).

~~~
joshuamorton
I'm aware. My statement still stands.

~~~
cjbprime
But the outline of PRISM described there seems to confirm (1) and (2), no?
They didn't need a subpoena for each user, had access to a search term
firehose, and the legal method for (2) was the secret FISA court.

The access isn't as complete as full arbitrary data, but it's also a long way
from only responding to known legal warrants and subpoenas.

------
mkhpalm
I'm usually confused why nobody ever mentions S/MIME. Its super easy to use
with Apple Mail.

------
mark_l_watson
I use ProtonMail as my primary email and when I exchange email with another
ProtonMail user, I feel that it is secure.

Great can be the enemy of good. Another example is Signal which gets some
criticism for being centralized. Signal is good. ProtonMail to ProtonMail mail
exchange is good.

------
virtualritz
What about civil disobedience as a motiv?

Maybe I'm aware that some entity, probably tied to a powerful player like a
nation state, can read my encrypted mails somehow.

But the more people are using encrypted mail the more difficult and expensive
this will be for this entity.

------
chicob
I fail to see an argument here. So the author thinks that PGP is not good.
Then the author argues against encrypted email?

I'm not sure whether to tag this under 'non sequitur' or ' throwing the baby
out with the bathwater'.

------
krick
This reminds me of how Pavel Durov every once in a while posts a story of some
recent WhatsApp/Signal/whatever fuck up, which ends up with a Cato-style
reminder of the fact we should switch to Telegram. Except, he is comparing
apples to apples, does this in kinda tongue-in-cheek manner and is
understandably endorsing his own product. None of which can be said about the
OP. So, unless you can name a better PGP+email replacement, all of it has
quite little value, and, no, Signal is not an email replacement, and, yes, we
still need email, so, sorry, cannot switch.

P.S. Does Signal still require a phone number?

~~~
FabHK
> P.S. Does Signal still require a phone number?

Yes, as the article mentions and (weakly, IMHO) justifies.

------
rsync
Setting aside the points in the article which are well taken and, for the most
part, things I agree with ...

If you run your own mailserver _and also if_ you send email to people on that
same mailserver, your email _never traverses a network_.

This use-case is not mentioned in the article, but should be. It is uncommon,
currently, but much less cumbersome and rife with pitfalls then trying (and
failing) to implement some kind of GPG regime, etc.

We do this at rsync.net - everyone uses the same mailserver, which we connect
to over either SSH or HTTPS, and when we send mail to each other it is _simply
a local copy operation_.

~~~
pvg
Why do you think it's uncommon? The zillions of people who communicate gmail-
to-gmail, in Gsuite, etc never have their mail traverse some external SMTP
network.

~~~
rsync
I guess I am speaking specifically of privacy-minded solutions that don't
involve a third party provider.

You are correct, of course, but when your email is handled by one of the FANGs
there is a wholly new, and different, kind of exposure happening.

------
Idunnonothing
This article came in a right time for me.

My team is assigned to think how to send "secure emails" to customers. The
thing is that those emails contain documents as attachments which can contain
names and social security numbers. Use case is that customer buy these
documents from our website and they can be delivered to email.

We already told that email is insecure by design to do things like that, but
now I am thinking about other possibilities. Best I can come up with is
encrypted attachment, but that's way too difficult for average customer to
open it with public key.

How have you handled situations like this?

~~~
dfabulich
Deliver the documents via your HTTPS website, secured with a username,
password, + 2FA if possible.

Send email just to notify the user that a document is available, providing a
link to your website.

------
msh
I think he is missing the point on archives.

Disappering/Nonstored is only a good thing in some contexts. There are several
type of communication that I want to be secure but also archived for later
reference or documentation.

------
zimmerfrei
Let's ignore for the moment the paternalistic and I-know-it-all tone
permeating the whole post...

> Most email encryption on the Internet is performative, done as a status
> signal or show of solidarity.

Where is the data supporting this statement?

Where can I read an quantitative analysis on how many emails on the Internet
are encrypted, and - out of those - the motivation for having them encrypted,
all by percentage? Really, I am willing to pay for it.

Or is the author basing it on personal anectodes, by looking at the few mails
in his personal mailbox?

Because at that point also my experience in the corporate world is as good as
theirs, and it actually proves the opposite on most points.

Over multiple years, I have seen PGP being used to secure all email exchanges
about product security with customers, suppliers, partners, security
researchers, and even competitors.

Not a single day passes without a PGP email being sent or received.

As far as I can tell, 100% of the emails contain information for objectively
sensitive topics (like security flaws, trade secrets, material under NDA,
etc).

Even though emails are exchanged with professionals that are skilled and
trained in IT security more than your average Joe, new contacts consistently
have PGP keys already and they know how to correctly use PGP.

Any suggestion to use Signal or wormholes won't make you look very good(for
good reasons), even though it is clear they are great security products.

Security is good enough: we know that because we do objective risk
assessments, where sensationalist articles on the Internet don't play a big
role.

I can't recall the last time people replied in the clear - though yes, it
happened in the past some times. It also happened that people copy & paste &
share paragraphs from sensitive emails though, which is as bad.

The main problem I see is not email encryption per se, but the first key
exchange. PGP keyservers are bad and avoided.

The second problem is usability, and it is appalling that nobody is able to
tackle this for PGP. It is not really rocket science and certainly people are
willing to pay for it.

>> Email is end-to-end unencrypted [1] by default.

>> Serious secure messengers foreclose on this possibility. Secure messengers
are encrypted by default

TCP is unencrypted by default too; actually and, you know what, it doesn't
even support encryption! You use TLS on top of it (in a hop-by-hop way
unfortunately).

Same thing for email. The fact that the underlying message is unsecured, does
not mean you need to throw it away.

>> Metadata is as important as content, and email leaks it.

This depends on your threat model. In ours, metadata largely doesn't matter.

>> Secure messaging systems make arrangements for “disappearing messages”.

You do understand that this is a big no-no for corporate right?

You must be able to set retention and escrow policies.

You must use data formats that are very likely to be around or re-
implementable in the years to come, not hipster apps that will disappear from
circulation next year. We love public standards or industry standards.

Sometimes retention rate is "never delete": that's necessary and it is OK.

------
mirimir
The real bottom line criticism of encrypted email is that people will screw
up, and leak metadata or plaintext.

But arguably that also applies to _any_ encrypted messaging system. Not just
email. So I'm not sure exactly what the point is.

About metadata: You can just anonymize it away. Maybe most people can't do
that. But then maybe most people will screw up in some other way.

Or rather, one could just build in anonymity.

Fundamentally, encryption isn't all that useful without ~anonymity. Because if
adversaries can find you, they can do whatever it takes to get what they want.
Or at least, to make your life Hell until you give it up.

And with adequate anonymity, those aren't issues.

> Messages can be material to a civil case and subject to discovery. They can
> be subpoenaed in a law enforcement action. They safeguard life-altering
> financial transactions. They protect confidential sources. They coordinate
> resistance to oppressive regimes.

Anonymity fixes most of those problems.

About Signal, until it gives up the phone number requirement, it's hopelessly
_not_ anonymous. And encryption without anonymity is pointless.

Edit: Maybe I'm still ranting, but less personally.

------
RedComet
Damn, that good to see that $50 million Signal recently received is already
being spent on marketing.

------
Legogris
Some of the arguments make perfect sense, some do not:

> If messages can be sent in plaintext, they will be sent in plaintext.

This is not an inherent problem with e-mail and can be solved with client
software. You can still have unencrypted communication while giving a big red
warning if a user sends an unencrypted reply to an encrypted conversation and
strip away quotes by default.

> Metadata is as important as content, and email leaks it.

This is true, but can I do think that this can theoretically be solved be a
new generation of server architecture while keeping the federated nature.

> Every archived message will eventually leak.

The problems here are a matter of implementation and what software is used.

> Every long term secret will eventually leak.

This is the one inherent problem with PGP e-mail in the entire post as I see
it. It is an issue.

All the issues the author bring up certainly hold true today but most of them
are not inherent to e-mail and I think with enough coordinated effort they can
be fixed while keeping decent compatibility.

I do think that apart from the metadata issue (not saying that this is to be
disocunted!), we could keep using the exact same servers as today in a
perfectly secure and private way if we have a new generation of e-mail clients
and e-mail cryptography.

As for the metadata part: I've been toying with the idea of a messaging system
using e-mail for transport but having an encrypted protocol on top of that
which solves these issues.

It would also require some way of distributing encrypted messages around
(maybe in a gossip-like protocol akin to SSB) and broadcasting gateway servers
that relay these messages on behalf of large amount of users.

Finally, there's something to be said with that PGP was ever only meant to
solve the secrecy, non-reputability and integrity of messages, which is only
part of a security and privacy story. It doesn't mean that PGP is broken, only
that it is incomplete depending on your threat model.

~~~
kbenson
>> Metadata is as important as content, and email leaks it.

> This is true

No, it _can_ be true. There are classes of communication where the metadata is
really not important. Like when my boss sends me an encrypted email with some
secure passwords we don't store in plaintext anywhere.

The metadata that shows it's from my boss and might have some identifying is
much less important than the fact I don't keep it in plaintext anywhere and it
wasn't sent in plaintext, yet I can get to it if needed.

~~~
Legogris
I might have been unclear, I mean what OP is positing under that headline in
the article is true. So, the e-mail leaking it part.

If you read my whole comment I finish with that it depends on your threat
model, which is basically what you're saying.

~~~
kbenson
Sure, I just think it's worth noting again and calling out explicitly, given
that there's a lot of assertions that are being made, but some are only
accurate in some use cases. It's either a lack of understanding on the
author's side, or a rhetoric tactic that I have little respect for. In either
case I think it deserves attention.

To some degree, it's not even the threat model which is different, but
people's entire use, which _of course_ might change the threat model. The
article is treating email as if it's the same as messaging, which it
emphatically is not. Email is also the de-facto method of exchanging file for
certain types of people (even if it's always been somewhat poor at it), or
providing explicit information that should stay around to individuals that
isn't desired to be on a website.

Email has always been somewhat poor at the use case of instant messaging, but
that's okay, it does other things much better than instant messaging (try
finding an instant message from ten years ago and migrating it from the
service it was on to a new one). Saying that it's not as good as the security
models of instant messaging when being used like an instant messager is not a
good reason to stop using it entirely. There are other reasons given that are
more compelling, but this one seemed to so fundamentally misunderstand what
some people use email for that I though it was important to note.

------
asimpletune
> So, for example, it recently turned out to be possible for eavesdroppers to
> decrypt messages without a key, simply by tampering with encrypted messages

Does anyone know the background behind this?

~~~
qqii
I believe they are referring to [https://efail.de/](https://efail.de/)

~~~
asimpletune
Ah, so they’re not referring to pgp per se, but the fact that email clients
will just execute any decrypted content embedded in the email.

~~~
lvh
"Per se" is doing a lot of work there.

When 'tptacek first heard of efail, we were both in the office, he called me
over and said "if there was a disastrous GPG bug that fails in way $X, what
would it look like" and my first answer was "of course it's that MDCs don't
actually work and the packet stream is malleable and something is going to
consume unauthenticated plaintext". That's not because I'm some sort of
genius: it's because to anyone who has studied the protocol and has a
cryptographic background, those flaws are glaring.

That matters because I think it's reasonable to blame a protocol when it is
indisputably flawed (there is no debate about MDCs not being a MAC, there is
no debate that authenticated encryption is important) and it turns out those
flaws all but imply vulns.

------
rrfgh
I have matrix - synapse with riot running at home for a year now, based on
yunohost.org in a virtual machine. Private chat and (video)calling for my
family andere friends.

------
rrfgh
I have matrix - synapse with riot running at home for a year now, based on
yunohost in a virtual machine. Private chat and (video)calling for my family
andere friends.

------
rrfgh
I have matrix - synapse with riot running at home for a year now, based on
yunohost in a virtual machine. Private chat and (video)calling for my family
andere friends

------
kubanczyk
Not LARP. I think the canonical term is _cargo cult_.

Although pretty offensive, at least the term clearly signals that the intent
is valid, as much as the methods aren't.

~~~
tptacek
The point of the comparison is that people are carelessly doing things that
would ordinarily be hazardous, but aren't, because the stakes aren't real for
them. They're then actively recommending those same reckless things to people
for whom the stakes are very real.

How you know the stakes aren't the same is that technologists by all outward
appearances care more about ergonomics than security (and, indeed, their own
idiosyncratic ergonomics, like "federation" and "works with email clients
nobody else uses"). If the stakes for nerds were real, nobody would be fucking
around with broken crypto. But they're LARPing.

------
fortran77
He _really_ doesn't like LARPers.

~~~
tptacek
I have no problem with LARPers at all.

~~~
fortran77
That's too bad.

------
tcd
I generally can agree with this. Encryption is a distraction from the real
issue: the weakest chain in the link.

We've recently seen recordings of meeting with Trump and associates. _No one_
is safe.

You must assume your every tap on a smartphone, you every keystroke and
interaction with a computer is being logged in some way. You interact with
computers by proxy - people entering information on your behalf, perhaps other
devices are listening to you, or logging your movements/interactions within
the world, perhaps taking videos and pictures of yourself. Profiling who you
are, who you talk to, what your financial situation is like, who you care most
about, who you align with, your network; colleagues, close and distant
friends, those you once interacted with but not so much. A brain capable of
recording every minute detail that you may want to forget. Details can be
recalled within seconds and just a few keystrokes, a second by second
recording in ultra high quality and the density of information being stored is
unmatched to any other time in history.

If somebody wants to get your information, they _will_ get it, one way or
another. This much has been proven true again and again.

So sure, use your fancy tools and gadgets, but be clear, one day, it's highly
likely what you wanted to keep private may become public.

When, not if.

------
diebeforei485
Well, certain countries block traffic to Signal and other encrypted apps.

As far as I know, in pretty much any country where you can send e-mail, you
can also send an PGP encrypted e-mail.

So, Signal is not a universal solution.

~~~
tptacek
If I ran a state-level intelligence service I too would try to get everyone in
my country to use PGP encrypted email instead of Signal.

~~~
diebeforei485
Sure, but "stop using encrypted email" implies everyone would have to use
plaintext instead of Signal.

~~~
tptacek
_Or not send dangerous messages electronically at all._

Fortunately, there's no place in the world where encrypted email is your only
option.

------
giomasce
I can agree with all the PGP bashing in the world, but it seems to me that PGP
provides one thing that apparently nobody else cares about, and I don't
understand why: the thing is identity verification. When I encrypt or sign I
don't just do it for the sake of itself: I want to be sure to whom I am
encrypting and from whom I am verifying a signature. If I am not sure of what
is the link between the used key and an actual person, organization or
service, crypto is not very useful for me. PGP has a way to do that. We can
speak for hours of its pitfalls, but it's there, and with same care it can be
used.

Do the alternatives have anything similar? I don't think so. Signal and
WhatsApp basically rely on a GSM identity (a telephone number), which is
verified by checking a six-digits code by SMS. There are hundreds of ways to
screw this up. Any random street pickpocket would be able to get your phone,
read the code and put it back in your pocket without you even noticing, not
mentioning attack on the actual GSM protocol of which I do not know much (but
have heard of its insecurity more than once). It's true that there is Perfect
Forward Secrecy and your peers will get a little notice saying that your
security code has changed (and will most probably ignore it), but if it is so
easy to take over one's identity, I don't think I can put much trust if the
system as a whole. (also, OP complains that GPG is a complex and obscure
implementation; what are they going to say about GSM stacks?)

Ironically, the thing that would make this system secure would be that people
actually checked security codes, which would basically amount to what PGP
users do when they exchange fingerprints (and I am sure OP would consider that
the LARPmost possible thing in the universe). Not even with the advantage of
having a proper Web of Trust, though.

Even TLS, although it is not mentioned by OP, has quite a few problems. Most
TLS certificates are Domain Validating, and the validation procedure
essentially consists in recovering a secret file by mean of an HTTP request to
that domain (surely that's true for Let's Encrypt, but I believe that most
commercial DV operators work in the same way, except that you have to pay for
it). So as soon as you're able to MITM the domain validation (and there are a
lot of actors who are able to) you can grab the certificate, which would in
theory protect from those who are able to MITM your server. This mechanism
still protects your from MITMs positioned close to the client, that's true and
it's better than nothing. But you still have all the holes you want. And bad
examples of TLS CAs are nothing near missing.

So, bottom line: I am very happy if you give me modern and advanced tools for
encrypting stuff, but please do not ignore the problem of giving names to
keys, a problem that as far as I know only PGP is currently able to tackle.

~~~
isodude
> So, bottom line: I am very happy if you give me modern and advanced tools
> for encrypting stuff, but please do not ignore the problem of giving names
> to keys, a problem that as far as I know only PGP is currently able to
> tackle.

I think that SQRL (grc.com) gives us hope here. Focusing on making is easy for
people in general to keep a secret signing device would be a big leap forward,
since you can base other identity service on that. Add Matrix to that and you
get identity as well.

------
WaitWaitWha
The reasons of presumed eventuallity is a horrible reason not to do something.

------
nextlevelwizard
Nice try NSA

------
Idunnonothing
ad

------
allovernow
>Ordinary people don’t exchange email messages that any powerful adversary
would bother to read, and for those people, encrypted email is LARP security.

We are literally living in an age where the NSA is spoofing cell towers to
intercept and save unencrypted (and probably encrypted) traffic to a database
that will probably be around as long as the NSA exists. This is naive and
everyone should be taking precautions against the kind of power that a true
authoritarian government would literally kill for.

I'm also personally insulted to be accused of LARPing for taking steps to
preserve my privacy. Even if something like protonmail isn't perfect, assuming
it isn't compromised it's orders of magnitude better than outlook, Google, et
al who are literally scanning your messages.

Edit: let me clarify my point, because people seem to be misinterpreting what
I'm saying. The fact that encrypted email is partially broken does not mean
that it doesn't currently reduce the leak surface. If I send 5 emails from a
service like protonmail to @outlook.com and 5 emails to @gmail.com, that's two
fractured datasets vs sending 10 from a Gmail account where they're all
scanned into one database. Locks are trivially picked but that doesn't mean
I'm LARPing to everytime I leave my house and lock my doors.

~~~
tptacek
If your adversary is NSA, and your defense is Protonmail, you are literally
LARPing. You don't believe Protonmail protects you from NSA; the reason you're
using it is because you know what you're sending and receiving isn't
interesting enough to target. If you had real secrets, you would not send them
through a Protonmail-encrypted email; you would make other arrangements.

~~~
allovernow
You're ok with Google and Microsoft building a profile of intimate details on
everyone who uses their services?

This isn't about having an adversary now, this is about minimizing future
risk. A database of personal data is one index or scan away from being used to
Target someone. Imagine what the Soviet government could do with information
about your purchasing habits, organization membership, political leanings,
religious participation. It's happening right now in China.

The fact that you don't have anything nefarious to hide doesn't mean you
shouldn't be worried about the existence of such databases. I'm not hiding
drug and weapons deals from the NSA, I'm trying to minimize how much
information about myself leaks to people who have no business collecting it.
All people should be similarly cautious. Unfortunately this isn't the kind of
thing that matters to most until it's too late.

How many laws or executive orders or judge rulings do you think it would take
before even the U.S. government could trivially abuse such information to
target someone? What if you're a whistleblower like Assange? What if you piss
off the wrong police officer? You haven't heard of corrupt cops harassing
citizens and who stuck their neck out a little too far?

Bad actors exist all over society. It is only rational to minimize the amount
of ammunition they may have against you, even if you aren't planning anything
nefarious. The problem with this kind of digital surveillance, regardless of
whether it is by government or corporation, is that the stored data is
permanent and easily harnessed. Let's not even get into the power that such
bits and pieces confer to actors with access to even simple ML technology.

I don't understand the reaction that people seem to have toward the desire for
maximizing privacy.

~~~
tptacek
I honestly don't care what superficial steps you take towards minimizing
dragnet surveillance. Go right ahead. My problem is with communicating to
ordinary people that encrypted email is reasonably safe to use to protect
secrets. It is not.

~~~
allovernow
It's substantially better than nothing, is it not? Do you disagree that it
requires more effort on the part of a malicious actor when emails are sent
from on ostensibly encrypted email service?

Do your house doors not have locks because locks are easy to pick?

Further, wouldn't encrypted email, even in current implementation, be much
more effective in keeping secrets if everyone used it? You can do much less
with metadata than with email contents, and the fact that leaks of plaintext
archives may happen eventually doesn't mean that all archives will be leaked.

The article has a valid point but shaming people by accusing them of larping
is IMO irresponsible.

~~~
tptacek
Encrypted email is not substantially better than nothing in the cases where
security actually matters. If the metadata of your message can get you
arrested, or if an accidental plaintext reply to a message can get your bank
account zeroed out, then using a system that carries those risks is _worse
than nothing_. When we talk about secure messaging, those are the use cases we
must consider.

------
jstewartmobile
" _encryption on the Internet is performative_ "

Security on _computers_ is performative. Intel, Cisco, Broadcom, Apple,
Google, deep state, and God only knows who else can crack these pieces of
garbage like an egg.

Whoever wrote this is _also_ a LARPer.

------
angry_octet
tptacek is right as usual, but everyone should still check out the excellent
mailpile: [https://www.mailpile.is/](https://www.mailpile.is/)

It integrates GPG really nicely.

------
Mikhail_K
Author advocates "wormhole" as the alternative to pgp for sending files. It is
written in Python. "Python" and "security" (or "good software engineering") do
not belong in the same sentence.

------
418tpot
So the general advice seems to be, stop using federated protocol and start
using... signal?

I find it hard to believe that an app that runs in electron and falls for
basic web security 101 XSS exploits[1] is a more secure solution than using an
encryption layer on top of a federated protocol.

[1]
[https://news.ycombinator.com/item?id=17050754](https://news.ycombinator.com/item?id=17050754)

~~~
telotortium
What on earth does a "federated protocol" have to do whether an app runs in
Electron?

------
stazz1
If I encrypt a message and put the secret on an sd-card I hand to my friend at
the park, I can mail him encrypted messages over plaintext e-mail and we are
safe.

Most people don't use it this way, but to say it's impossible to secure e-mail
is arrogant and not true

~~~
carterehsmith
One of the concerns with email that article raised was: the recipient can
click on "reply" \-- without encrypting the reply message -- which would send
the response together with the original message "quoted" \- all of that
unencrypted. This is apparently common operational mistake.

Note that this has nothing to do with key exchange, ie putting it on sd card
or whatever, would not change anything about the issue raised above.

There is also about a dozen other issues that the article lists, worth reading
for sure.

~~~
stazz1
Oh yeah that's a huge flaw in implementation (that probably every main e-mail
vendor is guilty of). If it's prevalent enough, then the article is warranted,
but the title and the conclusion are still gross simplifications -- it's not
like the piping is inherently flawed, it's just that we prefer clear viewing
windows to interact with messages, and where these two trains cross is where
privacy meets your eyeball and also meets oxygen. Really, all decryption
should happen on-device; but we cannot afford to abandon indecipherable
messages on a daily or hourly basis in favor of universal privacy. It's
somewhat reminiscent of the LOSE_POINTS_TO_LAG flag in quake and setting it to
false. Maybe a better title would be Encrypted Email quickly becomes
Unencrypted

------
leshokunin
I understand that sending email in plaintext is a design issue for email. And
that PGP is outdated.

However, I think it’s possible to have a system completely in the open and
still be secure. Bitcoin comes to mind. I don’t think the problem is with
email, but with the lax encryption models and the lack of support by email
clients and servers alike. Wouldn’t you agree?

~~~
lvh
"Completely open" is not the only useful property to discuss about a system.
Email itself is still fundamentally terrible for secure messaging.

Your argument seems to boil down to: "bitcoin is open", "bitcoin can $X",
"email is like bitcoin", therefore "email can $X". There are a few flaws in
that argument. Firstly, Bitcoin is pseudonymous, it makes no attempt to hide
transaction details, which obviously message security would need. Secondly,
even if the properties of bitcoin were relevant to messaging, at best you've
made the argument that "a system with public transaction records can still do
what you need for safe messaging", but not "email specifically can do what you
need".

There are two ways I could see your argument working out and both are
pathological examples. We can do secure comms over TCP, so just design a
secure comms system and then all the way at the end choose a blockchain or
email as your transport. That sounds true, but also doesn't seem like a useful
thought tool that results in improving anyone's communication security
tomorrow.

~~~
leshokunin
I'm not sure why you feel like calling my arguments pathological, or a false
equivalence. I'll disregard this.

I did not introduce any equivalence about valuation in my argument. I used
Bitcoin as an example of a well known open database, where everyone can see
the data (arguably an analog to plaintext exchanges) and yet it's secure.

Additionally, your point about Bitcoin being pseudonymous also applies to
email. You may create your own address, on any number of servers. At a high
level, it feels like the pseudonimity is essentially the same.

Are you proposing people stop using email and switch to a more secure
messaging system, like Signal? Or maybe to make an email app on top of tech
similar to Signal (kind of like Protomail?), or to improve email by baking in
modern security standards?

~~~
lvh
I did not call your arguments pathological, I called my own examples
pathological to clarify that I am not trying to strawman you: I appreciate
that my own examples are almost certainly not what people have in mind when
they talk about email security.

The pseudonymity is precisely one of the reasons e-mail does not work well.
One of the features of secure messaging as it is commonly understood is
participant privacy: hiding who participates and ideally when. This is the
metadata leakage problem described in the post.

You're restating your argument of "bitcoin is public and yet it is secure and
so it is possible to have secure systems that are public". I understand that,
but you don't appear to have engaged with my counterargument: "secure" is not
a universal term, and things that are fine bitcoin transactions are not
necessarily fine for secure messaging.

Protonmail does not seem like "tech similar to Signal" to me at all. I'm all
for implementing stuff like MTA-STS, and I appreciate e-mail isn't going to
die any time soon. I think that trying to add E2E-style encryption to e-mail
is fundamentally doomed, signing for e-mail is mostly doomed, and yes, private
conversations belong on something like Signal.

~~~
leshokunin
I appreciate the clarification, thanks.

It’s interesting that you feel email has a lot of traction and is broken, but
you see that as an argument for moving away from it. I would think it’s an
opportunity to fix that system, since users are unlikely to switch. I’ve
thought quite a bit about what making email like Signal would look like, but
I’m curious what’s your take on the overall problem.

~~~
lvh
I do not think it is meaningfully possible to fix that system (I say
meaningfully, because I'm excepting the pathological senses I mentioned
above). If you want it to look, feel like email and be compatible, you can't
secure it.

MTA-STS works because it does not require end users to do anything. If you
need end users to change their workflow, you could try to do that with e-mail
(which fundamentally can't do all the things you need it, per the post and the
PGP post), or you can just make them use a non-broken protocol.

~~~
leshokunin
I guess I don’t understand why you would think that the following wouldn’t
work: \- use random email addresses \- encrypt the content with something more
secure than PGP (on the client) \- receive the email and decrypt it (on the
client)

Sure, it’s plaintext, but I don’t see the downside?

~~~
lvh
How do I securely communicate what the new email address is? How do I hide IP-
level metadata? How do I hide time-level metadata? How do I do PFS?

At some point you're going to keep adding lipstick to the pig until eventually
you have something morally equivalent to the pathological example I gave.

~~~
leshokunin
That's interesting. Thanks for taking the time to expand on it.

------
vbezhenar
If I'm using GPG, I want to ensure:

1\. The message I received is from person possessing private key (signing).

2\. The message I received is not available to Google or any other 3-rd party.

GPG is good old dumb tool that deals with crypto. I can save e-mail into text
file and use it with GPG. I can even copy that text file to an offline
computer if I don't want to risk exposing key.

Signal is just yet another whatsapp competitor? I don't want to publish my
phone number. I don't want to trust some random application from AppStore. I
don't want my correspondence to go through some untrusted servers (and I trust
Google servers much more than Signal servers). Especially servers controlled
by the same person who wrote an application. I have no idea how to be sure
that message I got corresponds to a public key that person gave me when we met
last time. How do I extract message source from Signal? What's are console
tools to deal with it? How do I deal with new key issuance if person
reinstalled his application?

GPG have answers for those questions. Signal does not. Basically GPG is
encryption for nerds, Signal is encryption for ordinary people. It's
important, but not particularly interesting for me and it's not a replacement.
Especially given the fact that Whatsapp and Telegram provide E2E and they are
much more widely used.

Basically GPG is good enough and we don't need nothing more than that. And
that GPG critique is just manipulation of facts. When my Debian distribution
will use Signal to verify packages, I'll consider using it.

