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 <i>actually</i> care about the cryptographic security of our emails, most of the time.
As someone who worked as a pen-tester, security is almost ALWAYS at odds with convenience.<p>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.<p>Maybe a synonym for "turned on by default" is "absolutely zero inconvenience or attention needed"
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.<p>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.<p>And it improves their security in a couple ways too.<p>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 <i></i>zero<i></i>.<p>We can talk about making the UX better. But unless it's effort-free and happens by default, there's no motivation.
An emerging HN trope is that “almost no one uses PGP.”<p>PGP remains wildly popular on Tor cryptomarkets, an area where users assume server compromise will happen yet still decide to transact using encrypted messages.<p>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.
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...<p>Just get an email client that has PGP capability built in.
And the sad thing is that even if you do succeed in using encrypted email with PGP, as <a href="https://latacora.micro.blog/2019/07/16/the-pgp-problem.html" rel="nofollow">https://latacora.micro.blog/2019/07/16/the-pgp-problem.html</a> says, you're taking an approach that cryptographers recommend against.
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.
> Each public key must be signed before messages from the owner of that public key can be decrypted.<p>Nope.<p>> Your public key must be sent to anyone to whom you send an encrypted email.<p>Nope, you need theirs.<p>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.
The UIs are terrible.<p>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.<p>Multiple devices -> yeah, that's tough too. They need the private keys. They need to keep their own indices.<p>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.<p>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.
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.<p><i>EDIT</i>: 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.
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.<p>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)?
With GPG, sure.<p>I have GPG keys (for other reasons) which I never use for email.<p>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.
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.
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.
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.<p>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.<p><a href="https://en.wikipedia.org/wiki/Transport_Layer_Security" rel="nofollow">https://en.wikipedia.org/wiki/Transport_Layer_Security</a><p>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.<p>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.<p>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.
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.
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.
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."<p>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.<p>This is the very base that async crypto is based on.
Encrypted mail will not be “solved” until Google, Yahoo, & Microsoft decide you do something about it. Until then it’s just a pipe dream.<p>Yes that’s harsh. Yes that’s what I truly believe.<p>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).
These two ars technica articles are a really good breakdown on both sides of the issue, but I agree with the first.<p>Use keybase. It's easier!<p>[1] <a href="https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/" rel="nofollow">https://arstechnica.com/information-technology/2016/12/op-ed...</a>
[2] <a href="https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/" rel="nofollow">https://arstechnica.com/information-technology/2016/12/signa...</a>
I wonder if said acquaintance had started with something like Tutanota or DeltaChat, if the user would have had a less frustrating experience.<p>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.<p>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.
Sorry but this is not about encrypted email but the sheer suckiness of GPG.<p>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.<p>However GPG is the one tool that I find has just about the worst UI.<p>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.
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.<p>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...
Why can't secure email be based on simple https-server?<p>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?<p>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?
>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.<p>Not to mention even Glenn Greenwald did not expend the effort to learn GnuPG, even when Snowden sent him a 10 minute tutorial.
I can feel the pain reading that post.<p>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".
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.<p>Highly recommend for personal use.
This article ignores certified email built into almost every email client.<p>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.<p>Both clients are set up for encrypted email through certificates. The UI is pretty slick in both cases, the docs looked pretty clear!<p>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.<p>Seems like if personal certs could be offered by a reliable CA, it would be pretty damn easy to use encrypted email.
15 minutes could save you 15% on your cybersecurity insurance or more: <a href="https://github.com/DataDog/yubikey" rel="nofollow">https://github.com/DataDog/yubikey</a>
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.<p>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?<p>1) Letters to you can only be read by you, using a secret decoder ring to ensure that no one else can.<p>2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it.<p>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.<p>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.<p>Loosely, these analogies translate as: GPG is #1, TLS SMTP is #2, SMTP is #3. (There's not really an analogy for #4.)<p>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.<p>That feature was discussed on HN at the time (4 years ago, 209 comments): <a href="https://news.ycombinator.com/item?id=11067050" rel="nofollow">https://news.ycombinator.com/item?id=11067050</a>