16 ms·

Now I understand why almost no one uses encrypted email

226 points by sT370ma2 6y ago

recrudesce 6y 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 6y 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 6y ago
  Unfortunately, it only gets marginally better. It is still way too painful for regular people to use.
- Majromax 6y 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/ 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-encrypt-stuff.html 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.
  - recrudesce 6y 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/ 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.
    - deleted 6y ago
      [deleted]
pge 6y 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 6y 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 6y 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.
- floatingatoll 6y 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 6y 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"
- happytoexplain 6y ago
  I'm a little baffled as to why this is getting downvoted. It seems so true and uncontroversial.
  - naasking 6y 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.
    - kube-system 6y ago
      > Consider the magnitude of inconvenience from having your identity stolen. I think it dwarfs any minor inconvniences needed to secure your identity. It's not as simple as a boolean situation, though. There's not any single set of security steps that a person can take to definitively 'secure their identity'. It's a gigantic continuum, where inconvenience asymptotically increases as you approach complete security. Everyone chooses some amount of risk which is less than complete security. The only real argument is over which point along the continuum is appropriate. There is no one correct answer, either.
    - deleted 6y ago
      [deleted]
- JoeAltmaier 6y ago
trishankdatadog 6y ago
15 minutes could save you 15% on your cybersecurity insurance or more: https://github.com/DataDog/yubikey https://github.com/DataDog/yubikey
- boromi 6y ago
  macos only guide? What about windows users?
tptacek 6y 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 6y 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 6y 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...
- hoistbypetard 6y 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 6y 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
- brnt 6y 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.
myu701 6y 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.
floatingatoll 6y 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 https://news.ycombinator.com/item?id=11067050
- 0xff00ffee 6y 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/ https://www.yubico.com/ As well as : https://google-authenticator.com/ https://google-authenticator.com/
  - floatingatoll 6y 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).
vortico 6y 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 6y 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.
0xff00ffee 6y 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.
- inetknght 6y 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.
  - floatingatoll 6y 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-certificates-in-2019/ https://davidroessli.com/logs/2019/09/free-smime-certificate...
  - WorldMaker 6y 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.)
buildbuildbuild 6y 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 6y ago
  So you mean to say is that PGP is wildly or only popular with criminals?
  - hermod 6y ago
    Which would be an excellent endorsement for PGP, provided that the said criminals don't get caught.
  - timerol 6y ago
    Conflating "people that practice good OpSec" and "criminals" is disingenuous.
  - exolymph 6y ago
    If criminals don't use your privacy tech, it probably doesn't work.
- snowwrestler 6y 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.
  - 6y ago
hprotagonist 6y ago
"Here's my burner number, hit me up on Signal." job done, assuming you want to transmit files under 100 MB/message.
- buildbuildbuild 6y ago
  Safe communication in 2020 does not require buying a tracking device and sharing its ID number.
btilly 6y 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 https://latacora.micro.blog/2019/07/16/the-pgp-problem.html says, you're taking an approach that cryptographers recommend against.
- nagsil 6y 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?
  - btilly 6y 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_pg.html https://www.schneier.com/blog/archives/2016/12/giving_up_on_..., https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma..., https://dev.to/artis3n/encrypting-files-in-a-post-pgp-age-59bf 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.
- upofadown 6y 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 6y 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 6y ago
  There's an addon called Enigmail that does exactly this.
AdamJacobMuller 6y 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 6y 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 6y 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 6y 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 6y 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 https://en.wikipedia.org/wiki/Layered_Service_Provider
leephillips 6y 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 6y 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.
  - leephillips 6y ago
    Fair enough.
- alkonaut 6y 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.
upofadown 6y 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 6y ago
  So what guide would you recommend?
  - upofadown 6y ago
    Riseup.net has a fairly extensive discussion: https://riseup.net/en/security/message-security https://riseup.net/en/security/message-security FSF is a bit more to the point for the casual user: * https://emailselfdefense.fsf.org/en/ https://emailselfdefense.fsf.org/en/ It is not always clear to the casual user if they are using gpg1 or gpg2. You pretty much always want to use gpg2. This is a genuine issue with the gpg ecosystem.
admax88q 6y ago
Is it already time for the weekly "GPG has a bad interface" blog post?
sbuk 6y 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.
austincheney 6y 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 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.
- dredmorbius 6y 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.
  - austincheney 6y 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 https://en.wikipedia.org/wiki/Digital_signature
hoistbypetard 6y 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 6y 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.
  - hoistbypetard 6y 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.
    - inetknght 6y ago
08-15 6y 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 6y ago
  Seems like you are one of the only ( few ) people who caught this.
robertlf 6y 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 6y 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.
deleted 6y ago
[deleted]
mD5pPxMcS6fVWKE 6y 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 6y 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.
unnouinceput 6y 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.
- tyingq 6y ago
  That really only reinforces the headline though.
  - yarrel 6y 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.
    - tyingq 6y ago
      I don't imagine, if I picked 100 random people off the street, that they would get it either.
      - unnouinceput 6y ago
        And since we live in a modern world with integration of social services only going up I strongly believe this should be taught in school, same way base computer usability is being taught in middle school. In there a simple chapter should exists to deal with this and make kids aware that cybersecurity is a must nowadays. Then, and only then, your phrase will be false.
pkilgore 6y 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-im-giving-up-on-pgp/ https://arstechnica.com/information-technology/2016/12/op-ed... [2] https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...
musicale 6y ago
It seems like a very bad design that email messages from criminals and scammers are virtually indistinguishable from email messages from your bank.
- cryptonector 6y ago
  Criminals and scammers sure like that though.
cryptonector 6y 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 6y 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 6y 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 6y 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 6y 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?

226 points by sT370ma2 6y 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 6y 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 6y ago
Unfortunately, it only gets marginally better. It is still way too painful for regular people to use.
Majromax 6y 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/ 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-encrypt-stuff.html 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.
- recrudesce 6y 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/ 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.
  - deleted 6y ago
    [deleted]

pge 6y 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 6y 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 6y 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.
floatingatoll 6y 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 6y 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"

happytoexplain 6y ago
I'm a little baffled as to why this is getting downvoted. It seems so true and uncontroversial.
- naasking 6y 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.
  - kube-system 6y ago
    > Consider the magnitude of inconvenience from having your identity stolen. I think it dwarfs any minor inconvniences needed to secure your identity. It's not as simple as a boolean situation, though. There's not any single set of security steps that a person can take to definitively 'secure their identity'. It's a gigantic continuum, where inconvenience asymptotically increases as you approach complete security. Everyone chooses some amount of risk which is less than complete security. The only real argument is over which point along the continuum is appropriate. There is no one correct answer, either.
  - deleted 6y ago
    [deleted]
JoeAltmaier 6y ago

trishankdatadog 6y ago

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

boromi 6y ago
macos only guide? What about windows users?

tptacek 6y 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 6y 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 6y 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...
hoistbypetard 6y 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 6y 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
brnt 6y 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.

myu701 6y 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.

floatingatoll 6y 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 https://news.ycombinator.com/item?id=11067050

0xff00ffee 6y 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/ https://www.yubico.com/ As well as : https://google-authenticator.com/ https://google-authenticator.com/
- floatingatoll 6y 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).

vortico 6y 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 6y 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.

0xff00ffee 6y 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.

inetknght 6y 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.
- floatingatoll 6y 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-certificates-in-2019/ https://davidroessli.com/logs/2019/09/free-smime-certificate...
- WorldMaker 6y 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.)

buildbuildbuild 6y 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 6y ago
So you mean to say is that PGP is wildly or only popular with criminals?
- hermod 6y ago
  Which would be an excellent endorsement for PGP, provided that the said criminals don't get caught.
- timerol 6y ago
  Conflating "people that practice good OpSec" and "criminals" is disingenuous.
- exolymph 6y ago
  If criminals don't use your privacy tech, it probably doesn't work.
snowwrestler 6y 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.
- 6y ago

hprotagonist 6y ago

"Here's my burner number, hit me up on Signal." job done, assuming you want to transmit files under 100 MB/message.

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

btilly 6y 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 https://latacora.micro.blog/2019/07/16/the-pgp-problem.html says, you're taking an approach that cryptographers recommend against.

nagsil 6y 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?
- btilly 6y 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_pg.html https://www.schneier.com/blog/archives/2016/12/giving_up_on_..., https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma..., https://dev.to/artis3n/encrypting-files-in-a-post-pgp-age-59bf 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.
upofadown 6y 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 6y 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 6y ago
There's an addon called Enigmail that does exactly this.

AdamJacobMuller 6y 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 6y 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 6y 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 6y 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 6y 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 https://en.wikipedia.org/wiki/Layered_Service_Provider

leephillips 6y 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 6y 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.
- leephillips 6y ago
  Fair enough.
alkonaut 6y 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.

upofadown 6y 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 6y ago
So what guide would you recommend?
- upofadown 6y ago
  Riseup.net has a fairly extensive discussion: https://riseup.net/en/security/message-security https://riseup.net/en/security/message-security FSF is a bit more to the point for the casual user: * https://emailselfdefense.fsf.org/en/ https://emailselfdefense.fsf.org/en/ It is not always clear to the casual user if they are using gpg1 or gpg2. You pretty much always want to use gpg2. This is a genuine issue with the gpg ecosystem.

admax88q 6y ago

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

sbuk 6y 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.

austincheney 6y 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 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.

dredmorbius 6y 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.
- austincheney 6y 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 https://en.wikipedia.org/wiki/Digital_signature

hoistbypetard 6y 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 6y 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.
- hoistbypetard 6y 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.
  - inetknght 6y ago

08-15 6y 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 6y ago
Seems like you are one of the only ( few ) people who caught this.

robertlf 6y 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 6y 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.

deleted 6y ago

[deleted]

mD5pPxMcS6fVWKE 6y 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 6y 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.

unnouinceput 6y 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.

tyingq 6y ago
That really only reinforces the headline though.
- yarrel 6y 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.
  - tyingq 6y ago
    I don't imagine, if I picked 100 random people off the street, that they would get it either.
    - unnouinceput 6y ago
      And since we live in a modern world with integration of social services only going up I strongly believe this should be taught in school, same way base computer usability is being taught in middle school. In there a simple chapter should exists to deal with this and make kids aware that cybersecurity is a must nowadays. Then, and only then, your phrase will be false.

pkilgore 6y 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-im-giving-up-on-pgp/ https://arstechnica.com/information-technology/2016/12/op-ed... [2] https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...

musicale 6y ago

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

cryptonector 6y ago
Criminals and scammers sure like that though.

cryptonector 6y 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 6y 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 6y 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 6y 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 6y 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?