Now I understand why almost no one uses encrypted email

https://cheapskatesguide.org/articles/encrypted-email.html

by sT370ma2 • 6 years ago

226 216 6 years ago

recrudesce2• 6 years ago

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

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

serf• 6 years ago

agree completely.

encrypted email is broken, and a lot of that has to do with ui/ux problems; but the author is making this way harder than it has to be.

grandinj• 6 years ago

Unfortunately, it only gets marginally better. It is still way too painful for regular people to use.

Majromax• 6 years ago

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

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

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

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

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

recrudesce2• 6 years ago

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

https://protonmail.com/support/knowledge-base/how-to-use-pgp...

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

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

pge• 6 years ago

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

ipython• 6 years ago

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

SamWhited• 6 years ago

This is an orthogonal issue, not a bigger issue. The point of end to end encrypted email is that it doesn't sit unencrypted on the mail server. Whether it sits unencrypted on your client or not is something clients should work on, but it doesn't mean that using encrypted email in general isn't hard. I could equally say that the fact that metadata such as senders isn't encrypted is a problem, but that's not what this article is about. We can have that discussion, here just probably isn't the right place unless you're going to tie it back into why GPG is so hard to use somehow.

floatingatoll6• 6 years ago

There are no indications in this article that the user has at-rest plaintext on their mail server or in their local mail client. It's possible they aren't removing 'my-msg.txt' after they're done using it, or that the remote recipient is vulnerable to those issues, but that's unrelated to the user interface focus of this post.

bszupnick• 6 years ago

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

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

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

happytoexplain3• 6 years ago

I'm a little baffled as to why this is getting downvoted. It seems so true and uncontroversial.

naasking• 6 years ago

It seems true because people don't consider disasters, like the mortgage crisis, or this pandemic.

Consider the magnitude of inconvenience from having your identity stolen. I think it dwarfs any minor inconvniences needed to secure your identity.

That said, no doubt user-computer interaction should study security a little more I think.

JoeAltmaier3• 6 years ago

That's a leap, from 'some security' to 'absolutely zero inconvenience'. There's no middle ground? Don't we all use passwords now for many things? That's not zero attention needed.

happytoexplain3• 6 years ago

My interpretation of the parent post was not that there is no middle ground, but that if a user can use a service without engaging in an extra step to increase security, they will do so, no matter how easy the extra step is. Passwords are not an extra step - they are required.

0xff00ffee8• 6 years ago

Password managers have turned this into near-zero inconvenience: when I arrive at the login page my UID and PW are already filled in.

(I also have three hard tokens for from banks and investments, two ubikeys (both for LastPass, one in storage), and google authenticator on my iphone for anyone that offers it... so I've taken a step backward for added security.)

jandrese• 6 years ago

Often the mentality you will find is "any hole is a hole that will be exploited", so they make these incredibly difficult systems with perfect security that nobody ever uses because they're so hard to use.

SSH is flawed in that you have to trust the host the first time you connect to it. For most people this is a reasonable tradeoff, but for security nerds it can be an impossible barrier to adoption. This is why some SSH servers spit out big long hexcodes or weird picture things, you are supposed to securely message the owner of the server to verify it before you accept it. Details are of course left up to the user because any default system you set up will of course be exploited. It's head of line security exploits all the way down.

jidiculous• 6 years ago

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

tptacek2• 6 years ago

Yes.

NikolaeVarius2• 6 years ago

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

So, IMO the barrier is, "actually working"

https://github.com/signalapp/Signal-Android/issues/5253 https://github.com/signalapp/Signal-Android/search?q=missing...

vpEfljFL2• 6 years ago

Could you please explain to me why Signal is the superior messaging platform?

I can't understand why it requires ID/passport from you to use it. I guess if you want to use an encrypted messaging platform then you don't want it to be tied to the government issued ID.

p.s. you phone number is tied you your ID, so it's basically your ID

blablabla123• 6 years ago

That's just my opinion, but to me E2EE from Whatsapp/Signal/Telegram is just Marketing. The trust is worse than Trust on first use (TOFU) since it can change repeatedly, most people install it through the Play Store so one might argue that it is in a certain sense as secure as closed-source software and the whole key exchange is hidden from the user. Not to mention that most Smartphones are blackboxes to a large part and phone number based apps are vulnerable to sim hijacking (yes we see when the key changes, but nobody cares and it's difficult to reestablish the trust).

Probably depends on the use-case, but as a normal user that lives in a non-repressive state, there is little value in using Signal. (FWIW Signal uses central servers, so in a repressive state it can just be turned off?) GPG based security is superior and not tied to a blackbox platform...

ses1984• 6 years ago

Security is convenient. Losing your sensitive data is pretty damn inconvenient.

happytoexplain3• 6 years ago

This is true, but not pragmatic.

jerf2• 6 years ago

There is a useful idea called Pareto Optimality: https://en.wikipedia.org/wiki/Pareto_efficiency

If you measure two things, you can draw the "frontier" between them, sketching out the max of X that you can have while having an amount of Y. This will draw a graph where the lower left is the part you can reach, and the the upper right is the part you can't, e.g. you can't have 100% security and 100% usability.

When you are on that frontier, than the two things are in apparent opposition to each other, in the sense that you can't get more of one without having less of the other. However, if you are not on that frontier, then suddenly the conflict evaporates, because you can indeed have more of one without less of the other.

(Almost everything we ever talk about as software engineers being in "opposition" to each other is actually in this relationship. Sometimes optimality on one axis is so easy to achieve that it's still practical to discuss the two things as being in "opposition", but most of the time, before worrying about to things being in opposition it should first be checked that we are indeed on this optimality frontier. Otherwise we risk constraining our thoughts into a win/lose frame and miss the win/win options on the table.)

All of that is a lead up to my claim that the idea that GPG is on the Pareto frontier for usability and security doesn't pass the smell test. In fact it manages to have such a bad UI that it adversely impacts the security it can provide. It isn't just what git calls the "porcelain", either; some of the fundamental data structures GPG uses are just not quite right and produce fundamental confusion. It certainly doesn't help that the UI is so obscure that even a heavy user can be confused by everything that is going on.

GPG really needs a total UI overhaul, but I think this is one of those cases where the existence of an apparently "blessed" product (the GPG distribution itself) prevents anything better from being able to get enough of a foothold to succeed. If you waved a magic wand and made me the PM over the GPG product, I'd be putting out a call to the community to make a better UI, no holds barred (i.e., fundamental data structure changes are on the table and while I wouldn't necessarily want to promise a lack of backwards compatibility, don't be afraid to break it), and in a year we'll circle back around to the proposals and the GPG project itself will bless one of them. But that probably won't happen. (And I personally lack the bandwidth and the gpg street cred, so "why don't you do it" isn't a terribly practical response.)

hinkley2• 6 years ago

Turns out the Pareto frontier explains a big chunk of my thesis on performance vs readability.

6510• 6 years ago

If I say "Public private key cryptography" it is like music to my ears. The term is near poetic. The experience is so hard to explain I think I have to make a drawing.

https://i.ibb.co/DgQ82kt/gnuPG.png

sz4kerto2• 6 years ago

We're developing an electronic health record platform that stores data encrypted in a way that we don't have the decryption key. We don't have end-to-end encryption, but if you got a database dump then it'd be quite tricky to decrypt what's in it as data belonging to a person can be unlocked with a secret that the person has, and we don't; only in memory when serving the user.

So we're very far from perfect, but still better than most providers in this space. However, the fact that we can't easily do database migrations, debugging, etc makes our lives extremely hard, and it's much more difficult to compete in terms of UX.

mazsa2• 6 years ago

FHE?

csours• 6 years ago

Making better security less and less inconvenient is the name of the game.

Bingo. It's really easy to overlook UX, but it's the name of the game for actually improving things. Dev Experience too. There's a perverse problem in secure development, where you need to know enough to figure out why something is going wrong, but you must not leak information.

jiggawatts• 6 years ago

security is almost ALWAYS at odds with convenience.

I hate this attitude. Vehemently. It's borderline ethically irresponsible to say it out loud, because it gives muggles the notion that they can save costs by reducing security, which is often simply not true.

Security is very often the cheaper option, or at least the smoother one. Certainly from an end-users' point of view, it's more convenient.

Let me list some examples:

Windows v1909 has a bunch of hardware-enfoced security turned on by default (=low admin effort), invisibly to the end user (=convenient). Older operating systems either have none of this, or it's a manual task to enable these optional features (=expensive).

A good HR automation process means that when a new employee starts, they automatically gain access to whatever they need, and nothing they don't. This is great for the user, because "everything just works" and they have everything they need available (=convenient), but it's secure because there is no error-prone manual processes to grant them access to things (=cheaper).

Windows 10 Hello for Business is essentially a virtual smart card stored in the TPM chip of your laptop, secured with a PIN or biometrics as a second factor. It uses modern cryptography and works transparently with Kerberos. It's as strong as a Smart Card but is more automatic than a password.(=convenient) It requires no hardware to deploy, and essentially eliminates a bunch of attack vectors (=cost neutral or even cheaper).

Simply enabling WSUS or leaving Windows in automatic patch mode is literally the cheapest and most secure option, yet many organisations insist on spending tons of time, effort, and money on "managing" their patches. This inevitably results in totally unnecessary paper pushing, and no measurable benefit. Meanwhile, Microsoft releases protocol-breaking changes (such as the CredSSP thing recently) in waves, with the "enabling" patch one month, and then the "enforcing" patch the next month. Smooth as silk. Except for every. Single. One. Of my customers that insisted on "managing" their patches in quarterly rollouts or whatever that had a major outage because they skipped patches.

You get the idea. There is a "happy" path of less effort, more convenience, yet very good security. Not perfect, but good enough.

Conversely, this attitude of "we must reduce security to reduce costs or improve convenience" is just insane. I've seen people go out of their way to purposefully weaken the default security of a system because of this logic.

So please. Even if you know better, just never, ever say anything like this out loud. The world is full of Muggles, and they hear this shit and do random stupid stuff that lets the Chinese government steal our hard work.

pfundstein• 6 years ago

Counterpoint: SSH, HTTPS, SMTPS, IMAPS, etc, all require no more interaction from the user than their insecure counterparts.

recursive4• 6 years ago

Counterpoint: I work for a company that sells software to mostly big companies. Sometimes they want to host it themselves. Creating valid certificates usable for HTTPS is a never-ending support issue.

wuunderbar• 6 years ago

SSH

Still requires a passphrase or initializing a keypair on the client & server.

HTTPS

HTTPS requires user interaction when a site forgets to renew a certificate.

Also SSH and HTTPS don't compare well. One does client authentication, the other doesn't.

trishankdatadog• 6 years ago

15 minutes could save you 15% on your cybersecurity insurance or more: https://github.com/DataDog/yubikey

boromi• 6 years ago

macos only guide? What about windows users?

tptacek2• 6 years ago

All of this of course skates past the problem that PGP's UX practically guarantees that someone will eventually reply to an encrypted email in plaintext, often compromising the whole conversation. Practically everyone who has used encrypted email "at scale" has seen it happen. An intolerable, irrevocable disaster we accept only because most of us don't actually care about the cryptographic security of our emails, most of the time.

ssully• 6 years ago

Even systems that try to improve upon the UX and simplify the process, like Entrust, still suffer from this problem.

PGP seemed almost like magic when I first used it, but I look forward to it being relegated to the history books.

barbs• 6 years ago

I think PGP has played an important part in propagating encrypted communication, and I think it's still quite useful as a tool for teaching/learning about asymmetric encryption, but there's just way too much friction for practical use for most people.

I wonder if there's some sort of educational tool/walkthrough that uses PGP under the hood but explains each step as you go...

hoistbypetard4• 6 years ago

I had a bug opened against evolution for something like a decade because it defaulted to using plaintext in replies to S/MIME encrypted emails. So it's far from only a PGP UX thing.

I'm still not sure they've fixed it... I haven't checked for several years now.

alfiedotwtf• 6 years ago

IIRC Outlook did the right thing by replying in ciphertext, but it also did the unhelpful thing of attaching the plaintext in a separate MIME part

brnt2• 6 years ago

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

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

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

upofadown5• 6 years ago

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

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

souterrain• 6 years ago

PGP has the best UX for its purpose: a social graph tool for nerds.

myu701• 6 years ago

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

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

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

floatingatoll6• 6 years ago

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

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

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

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

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

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

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

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

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

0xff00ffee8• 6 years ago

Secret decoder rings are cool, but they're not popular and they never will be.

Isn't this kind of a modern version?

https://www.yubico.com/

As well as :

https://google-authenticator.com/

floatingatoll6• 6 years ago

Those are both tools for storing a shared secret — one securely, one not so securely. Decoder rings are built upon the principles of a shared secret, but neither product supports "ciphertext" uses innately. You can build ciphertext processes on them, though I would discourage using TOTP secrets as your secret key since most authenticator apps make it difficult/impossible to access the secret key once it's stored (for security reasons).

saalweachter• 6 years ago

#4 are conversations carried on in comment sections or forums.

nybble412• 6 years ago

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

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

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

floatingatoll6• 6 years ago

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

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

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

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

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

vortico• 6 years ago

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

lgeorget• 6 years ago

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

0xff00ffee8• 6 years ago

This article ignores certified email built into almost every email client.

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

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

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

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

inetknght2• 6 years ago

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

floatingatoll6• 6 years ago

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

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

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

https://davidroessli.com/logs/2019/09/free-smime-certificate...

WorldMaker• 6 years ago

"LetsEncryptEmail" sounds like a good idea. It seems like there would be lessons to learn from Mozilla's Persona / BrowserID project which followed similar goals at a technical level. For instance, in addition to falling back to OTP codes sent to an email address for verification, they had a reasonably smart idea that you could use OIDC ("OpenID Connect") to validate logins more directly to at least major email providers like Gmail and Yahoo since many of the majors do have an OIDC endpoint or two.

(Mozilla Persona was a great project idea and a shame it never got enough market share. It didn't end up using personal certificates, though IIRC they explored that as an option and what they did use was technically very close.)

jamieweb• 6 years ago

I remember reading about Individual Validation (IV) certificates, which I believe were similar to Extended Validation (EV) certificates, but for individuals.

I don't think they ever really took off (or even existed), and there isn't anything in the Baseline Requirements / EV Guidelines as far as I know.

Nowadays they seem to be a bit of a myth, as there is very little evidence of them online except for use in code signing.

tialaramex5• 6 years ago

In principle nothing stops you creating such a CA.

The problem is, nothing stops anybody else creating such a CA. Why should I trust either of them? Why should anybody? Unless a critical mass trust the same CAs it's hopeless.

What you need there is a PKI, a Public Key Infrastructure. A PKI has two components, firstly some technical agreements like what sort of certificates are used, how to write email addresses and so on, for which you can mostly rely upon PKIX in this scenario - but then you also need some consensus on the much more difficult and political trust problem.

Mostly what happens is that PKIs are relatively small and private. EMV ("Chip and PIN" cards) has its own private PKI managed by EMVCo, the RIRs have one for route management called RPKI, lots of businesses have their own. Apple and Microsoft operate PKIs for "code signing" of various sorts.

And there's one obvious public PKI, the Web PKI, which is why your browser agrees with mine that this is https://news.ycombinator.com/

But there isn't one for email. So the far trickier problem than spinning up some "LetsEncrypt like service for personal certificates" is building that PKI.

jschwartzi• 6 years ago

CA certificate signing is orthogonal to encryption. If you only need to encrypt an email then a public key is sufficient. However if you also need a proof that you are who you say you are, then you would need a certificate that is authenticated by your PKI plus a public encryption key.

It's strange to me that any tool that simply encrypts email requires a CA-signed certificate instead of a simple public key or a self-signed certificate. Self-signing is totally okay provided you have a way to distribute your certificate that allows the recipient to authenticate that it came from you. Then they can simply add your certificate to their list of trusted certificates.

0xff00ffee8• 6 years ago

CA certificate signing is orthogonal to encryption.

Yes in the broad sense and no in the specific case.

In order to activate macOS Mail encryption you need a certificate on your keychain. So by having a CA issue you a certificate, the mail client can generate the keys to encrypt that mail without additional passwords (e.g., relying on in-situ authentication). So in this application they are interrelated.

techntoke5• 6 years ago

Or you know, just use PGP/GPG (which have public keyservers) and forget about CA.

firebird842• 6 years ago

Did you try instantssl? https://secure.instantssl.com/products/frontpage?area=Secure...

0xff00ffee8• 6 years ago

Weird, that was surprisingly easy. Wonder why that didn't show up in my search...

indymike• 6 years ago

A LetsEncrypt for email would be a game changer.

buildbuildbuild2• 6 years ago

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

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

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

louwrentius• 6 years ago

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

hermod• 6 years ago

Which would be an excellent endorsement for PGP, provided that the said criminals don't get caught.

timerol• 6 years ago

Conflating "people that practice good OpSec" and "criminals" is disingenuous.

exolymph• 6 years ago

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

snowwrestler• 6 years ago

I think a lot of people think about encryption technologies in terms of global adoption. HTTPS, encrypted filesystems, and E2E encrypted messaging have all reached a significant percentage of global Internet users.

But in that context, 50k PGP users is arguably "almost no one." If we guesstimate 4 billion Internet users, that's 0.001% of all users.

I think the point is not that PGP is impossible to use, I think the point is that PGP is not appropriate to scale to the global Internet the way other encryption technologies have.

a3_nm• 6 years ago

It's not true that something isn't valuable just because it hasn't scaled.

PGP has an outdated and confusing UX, a broken threat model, and is extremely bad in many respects. But it does have users, and for some people and some tasks, it works better than alternatives. (My use cases: exchanging routine work email with other nerds who have it set up, share confidential documents.)

So, while we shouldn't minimize its very major problems, we shouldn't pretend that its user base does not exist and that it's not addressing at least some use cases.

hprotagonist• 6 years ago

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

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

buildbuildbuild2• 6 years ago

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

btilly2• 6 years ago

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

nagsil• 6 years ago

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

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

People do this reflexively and upload almost anything.

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

btilly2• 6 years ago

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

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

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

upofadown5• 6 years ago

The someone disjointed and uninformed rant you have linked to contains this:

Encrypting Email >Don’t.

... which is obviously absurd. I think you might of been taken in by a troll attempt...

mikece• 6 years ago

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

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

7786655• 6 years ago

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

AdamJacobMuller• 6 years ago

With GPG, sure.

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

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

throw7• 6 years ago

I can feel the pain reading that post.

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

cuspycode• 6 years ago

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

Forbo• 6 years ago

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

tzs• 6 years ago

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

leephillips2• 6 years ago

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

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

beebob• 6 years ago

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

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

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

leephillips2• 6 years ago

Fair enough.

alkonaut• 6 years ago

The opposite take would be this: If you need to read a manual that’s a clear sign the system is too complex to be secure. The human is the weakest link so a system that relies on humans being intelligent or careful is insecure. Humans are going to be dumb, sloppy and in a hurry.

upofadown5• 6 years ago

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

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

mannykannot• 6 years ago

So what guide would you recommend?

upofadown5• 6 years ago

Riseup.net has a fairly extensive discussion:

https://riseup.net/en/security/message-security

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

* https://emailselfdefense.fsf.org/en/

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

admax88q• 6 years ago

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

sbuk• 6 years ago

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

austincheney9• 6 years ago

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

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

https://en.wikipedia.org/wiki/Transport_Layer_Security

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

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

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

dredmorbius5• 6 years ago

TLS doesn't require long-term access. All encryption is session encryption -- data-in-flight. There's no data- or access-loss with key expiry (though there's a potential for data intercept with even session-key compromise). Keysystems such as SSH are similar in this regard.

Encrypted email, and all data-at-rest encryption require long-term key retention and confidentiality. Loss of a key means loss of data. Disclosure of a key means loss of confidentiality.

TLS / data-in-flight is a tremendously simpler problem than email / data-at-rest.

austincheney9• 6 years ago

Websites require long term certificate retention and every year or two those certificates are replaced just like email PKI keys are in an environment with key management. So, long term crypto storage in that regard is equivalent between email and the web. The fact that the PKI keys of TLS are temporary are more out of convenience than security because the client/server have to work out which key set algorithm is agreeable.

You don't generally need a certificate in addition to perform key exchange over email, though that is an option, because you either know and trust who you are manually exchanging keys with or the remote user is already trusted because you are both on the same server that is automating the exchange. On the web everything is anonymous so there is no trust without that certificate. If you really want one though modern email clients will allow you to create a personal certificate and digital signature to establish identity.

Key exchange isn't meant to provide identity. That is what signed certificates are for. The keys are only there to provide distributed encryption. Most modern email clients will allow you to generate a certificate for your emails with a digital signature.

https://en.wikipedia.org/wiki/Digital_signature

Shendare2• 6 years ago

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

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

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

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

austincheney9• 6 years ago

The keys don’t come from the servers but from the end users, so the remote server won’t have the remote user’s key.

Or they could let their provider hold onto a copy of the private key

Then the key is no longer private. The idea of a private key is not to share or distribute it.

boneitis2• 6 years ago

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

Brainstorms of a (mere) hobbyist:

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

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

zokier3• 6 years ago

email does not have an equivalent to TLS

Email does have the equivalent of TLS, its TLS. Send a message to another user in Facebook or whatev over the web and its secured by TLS over the wire, but does not protect from the server reading it. Send a email to user on an email server and its secured by TLS over the wire, but does not protect the server from reading it. Exactly the same thing.

austincheney9• 6 years ago

over the web

So this confuses a few things. Technically you are right in that TLS applies to the transport layer (layer 4) while both web and email are application layer (layer 7), but then the question is how to apply it for email in practice that differs from manual key exchange?

Web mail uses web (port 80 or 443) to communicate to a web server email application where the email is blasted out as regular email (most likely as SMTP over port 25). Since the first leg is regular web traffic regular web rules apply, but only to that first leg. Applications like Outlook and Thunderbird are not webmail and do not use web traffic to send/receive email.

tialaramex5• 6 years ago

Your layered model with "pipes" seems like a confusion and is misleading at best.

It's probably easiest to see what's actually going on the TLS 1.3 design - even though this is effectively what really happens in popular clients and servers with older TLS versions today also - because in TLS 1.3 none of it's optional any more.

In TLS 1.3 the peers agree an ephemeral shared "master" secret using an elliptic curve variant of the Diffie Hellman algorithm and random data they've chosen. ECDHE means each side ends up knowing the same essentially random secret and nobody else knows what that is, even if they eavesdropped on everything both peers said.

Then this shared secret is enough to generate a number of symmetric keys used to secure all subsequent communications between the peers with conventional symmetric encryption (often AES using the GCM cipher mode).

Now, the two peers can communicate securely, it is impossible for anyone to eavesdrop. But, at this stage neither is sure who the other is. It is conventional (in web browsers) for the client's identity to remain unknown in TLS but the server proves its identity using a signature algorithm. Specifically it signs a transcript of the process so far, proving that it took part in the sequence of events that led to this point, using a key for which it presents a certificate. The client can examine the certificate and signature and verify that the certificate is trustworthy and that the transcript signature proves that the certificate's subject is the server it is talking to.

There aren't two pipes, one contained within the other. There's just one pipe, a secure pipe between client and server, and then that pipe is used to transport proof of the server's identity (and optionally, likewise for the client). Without that identity the pipe is still secure, you just don't know who it is you're talking to securely.

austincheney9• 6 years ago

This website explains the distinct “pipes” better and more precisely than does the Wikipedia article: https://hpbn.co/transport-layer-security-tls/

Those pipes are the asymmetric handshake to exchange the shared secret and the symmetric encryption provided by that shared secret.

Certificates do not provide encryption and thus are not a “pipe”. Certificates are used to prove the identity of one of the end points (the server).

hoistbypetard4• 6 years ago

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

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

And it improves their security in a couple ways too.

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

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

bdamm• 6 years ago

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

hoistbypetard4• 6 years ago

Encryption is not signing, and relying on it to tell if someone has interfered with the content of a document has a track record of disaster.

You need to rely on signing for that.

Even if you're using an encryption scheme that claims to preserve integrity.

Signing is easier, because only the sender needs to set it up for it to be effective.

At any rate, I think I see your point, and that's why I chose the word "suffered." People have suffered from not using server side TLS. Practically no one knows of any consequence they've suffered for sticking to plaintext email.

matheusmoreira2• 6 years ago

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

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

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

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

aasasd• 6 years ago

Alas, in some places communications security and anonymity is a ‘black swan’ problem in that it's barely noticeable most of the time, but someday it might irreparably mess up one's life. So of course people are split into those who may occasionally think that it'd be nice to have encrypted messaging, and those who heard of the consequences and now worry about them like it's plague.

zokier3• 6 years ago

That is sadly related to the fact that email as a platform is pretty much dead outside small niches. Very few applications are built on top of email. Of course that is also chicken and egg problem; without good security story its bit difficult to build anything on it these days.

na854• 6 years ago

email as a platform is pretty much dead outside small niches.

Perhaps from the POV of The Valley, but I can assure you that email is alive and well elsewhere.

johannes12343213• 6 years ago

There is a key area where mail is central: The "I lost my password" feature of websites. Apple ID, Google+ (or whatever they call it now) and Facebook login replace it to some degree (especially on mobile device apps) but for far most websites newly created passwords or activation links are sent via regular mail unprotected.

akvadrako2• 6 years ago

This isn’t true. Lots of people have seen the news where leaked emails ruined people’s careers, Hillary Clinton being the most prominent.

chrismatheson2• 6 years ago

Are these sort of leaks usually from intercepting email? or some other method like, from a trusted participant in the conversation leaking them, a backup being found, the machine itself being compromised?

chrismatheson2• 6 years ago

would encryption, or at least a better UX around signatures not help reduce a lot of Phishing attacks?

08-15• 6 years ago

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

Nope.

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

Nope, you need theirs.

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

pinfisher• 6 years ago

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

robertlf• 6 years ago

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

markosaric• 6 years ago

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

mD5pPxMcS6fVWKE• 6 years ago

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

PacifyFish• 6 years ago

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

Highly recommend for personal use.

unnouinceput2• 6 years ago

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

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

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

tyingq2• 6 years ago

That really only reinforces the headline though.

yarrel• 6 years ago

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

pkilgore• 6 years ago

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

Use keybase. It's easier!

[1] https://arstechnica.com/information-technology/2016/12/op-ed... [2] https://arstechnica.com/information-technology/2016/12/signa...

musicale• 6 years ago

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

cryptonector2• 6 years ago

Criminals and scammers sure like that though.

cryptonector2• 6 years ago

The UIs are terrible.

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

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

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

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

missingrib• 6 years ago

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

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

badrabbit• 6 years ago

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

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

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

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

MR4D• 6 years ago

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

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

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

galaxyLogic• 6 years ago

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

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

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

Now I understand why almost no one uses encrypted email

Related Stories