Now I understand why almost no one uses encrypted email
cheapskatesguide.org
cheapskatesguide.org
PGP seemed almost like magic when I first used it, but I look forward to it being relegated to the history books.
I wonder if there's some sort of educational tool/walkthrough that uses PGP under the hood but explains each step as you go...
I'm still not sure they've fixed it... I haven't checked for several years now.
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.
I am an actual OpenPGP shill who is entirely in favour of a very conservative approach to the standard but I really don't see the problem here. Autocrypt is a separate standard. Clients can implement it completely and just switch the trust to OpenPGP if a PGP identity shows up. There is nothing wrong with a client adding some extra trust information to accommodate autocrypt.
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"
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.
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.
(I also have three hard tokens for from banks and investments, two ubikeys (both for LastPass, one in storage), and google authenticator on my iphone for anyone that offers it... so I've taken a step backward for added security.)
Which happens to also be more secure.
Hell, I store my 2FA keys in my pw manager and have it autofill those too -- a reduction in security! But there are some services that refuse to not spam your phone number if you don't set up some 2FA.
SSH is flawed in that you have to trust the host the first time you connect to it. For most people this is a reasonable tradeoff, but for security nerds it can be an impossible barrier to adoption. This is why some SSH servers spit out big long hexcodes or weird picture things, you are supposed to securely message the owner of the server to verify it before you accept it. Details are of course left up to the user because any default system you set up will of course be exploited. It's head of line security exploits all the way down.
So, IMO the barrier is, "actually working"
https://github.com/signalapp/Signal-Android/issues/5253 https://github.com/signalapp/Signal-Android/search?q=missing...
If they don't, anyone who has ever used Signal to communicate with them will be silently unable to contact them anymore.
I can't understand why it requires ID/passport from you to use it. I guess if you want to use an encrypted messaging platform then you don't want it to be tied to the government issued ID.
p.s. you phone number is tied you your ID, so it's basically your ID
It may not be for you, but Signal does a very good job of solving the problems it does aim to solve for the millions of people who use it.
[0]https://medium.com/@mshelton/using-signal-without-giving-you...
Probably depends on the use-case, but as a normal user that lives in a non-repressive state, there is little value in using Signal. (FWIW Signal uses central servers, so in a repressive state it can just be turned off?) GPG based security is superior and not tied to a blackbox platform...
"[A correspondent's security code which is the only way to be sure you aren't MITM'd] can change repeatedly": It will tell you this happened, allowing you to take whatever action you think is appropriate. Also like modern TLS the behaviour is that you are always protected by the protocol from passive eavesdroppers regardless. Pervasive Monitoring Is An Attack and so protection against this is far more than "just Marketing".
"Most people install it through the Play Store": Play Store APKs are signed by their creator, not (only) by Google. If Open Whisper Systems says you're getting Signal, Google don't get to substitute something else except if you buy a Google phone and only then by replacing your OS.
"Phone number based apps are vulnerable to SIM hijacking". Signal users can choose to "lock" their account with a PIN so that an apparently new phone with that number doesn't get access unless its owner presents the PIN.
Assuming that you think the phrase "non-repressive state" includes countries like the US that spend billions of dollars to spy on their own citizens, just the first item is already a huge benefit.
Harvesting every single SMS message is trivial and so undoubtedly the NSA does it, they can run simple keyword matching an statistical analysis, and keep everything in case it's interesting. Each SMS message carries the sender, recipient and full text. In contrast harvesting even the encrypted Signal messages is difficult, and even with a successful (and relatively unlikely) breach of Open Whisper Systems itself neither the contents or in most cases senders are revealed by doing this. (Messages to friends or to those happy to receive messages from strangers don't need to reveal who sent them to Signal's own systems, only to the recipient). So instantly such government bulk collection isn't possible.
GPG's security is definitely not "superior" because it's based on the PGP hybrid crypto which is from last century. For example there's no Forward Secrecy, so it makes sense to steal encrypted PGP data on the expectation that you'll some day be able to decrypt it. In contrast old Signal encrypted messages are probably completely useless because the keys needed to decrypt them likely no longer exist anywhere. PGP offers only a signature mechanism, so a recipient can prove you sent a message, whereas in Signal the recipient only has their own certainty that it's not a forgery - nobody else could have forged it, but they easily could and so they can't use that as proof of anything.
But it's only OWS that control that check, right?
> Harvesting every single SMS message is trivial and so undoubtedly the NSA does it, they can run simple keyword matching an statistical analysis, and keep everything in case it's interesting. Each SMS message carries the sender, recipient and full text. In contrast harvesting even the encrypted Signal messages is difficult, and even with a successful (and relatively unlikely) breach of Open Whisper Systems itself neither the contents or in most cases senders are revealed by doing this. (Messages to friends or to those happy to receive messages from strangers don't need to reveal who sent them to Signal's own systems, only to the recipient). So instantly such government bulk collection isn't possible.
Comparing to SMS is a strawman. If the best thing you can say for your crypto is that it's more secure than SMS, it sucks.
Practically Signal offers little advantage over any messenger with transport encryption (e.g. Facebook Messenger): in both cases you pretty much have to trust the organisation itself.
> GPG's security is definitely not "superior" because it's based on the PGP hybrid crypto which is from last century.
It's based on a mature cryptosystem which we know the NSA tried and failed to break. That's better than using something novel and unproven.
> For example there's no Forward Secrecy, so it makes sense to steal encrypted PGP data on the expectation that you'll some day be able to decrypt it. In contrast old Signal encrypted messages are probably completely useless because the keys needed to decrypt them likely no longer exist anywhere.
True as far as it goes (though the PGP standard has good support for key rotation via subkeys - it would be good to improve the UX around this), but think about your threat model - reading messages from 10 years ago might not be the biggest vulnerability. In contrast, using Signal means an attacker who gains access to one person's phone has immediate access to phone numbers for all their contacts - which for a government means probably getting immediate access to their names, addresses, and real-time locations.
Signal does do a few good things that PGP-based cryptosystems don't. But the downsides massively outweigh the upsides in my book.
There's a critical difference you're papering over: the level of trust that is required is very different. With transport encryption you have to trust that the infrastructure is secured on an ongoing basis. With end-to-end encryption implemented in a real-world app (i.e. distributed through a walled garden) you need only trust that the version of the app delivered to you is based on the code it claims to be.
> Signal does do a few good things that PGP-based cryptosystems don't. But the downsides massively outweigh the upsides in my book.
One of the things Signal does well that PGP systems don't is actually being usable by real humans, which for a security system is everything.
If we're talking about a government bulk surveillance programme then not really - servers and infrastructure change all the time and sysadmins are naturally curious. An ever-expanding pool of people at Facebook (or wherever) would have to be on board with the surveillance programme for it to be worth setting up.
> With end-to-end encryption implemented in a real-world app (i.e. distributed through a walled garden) you need only trust that the version of the app delivered to you is based on the code it claims to be.
Those walled gardens don't let you pin a fixed version of that app, and OWS stops people from redistributing the APK or putting it up on open-source app stores, with their rationale being that they can't handle old versions of the app using their servers. So in reality you have to trust them on an ongoing basis.
> One of the things Signal does well that PGP systems don't is actually being usable by real humans, which for a security system is everything.
Being secure is everything. Usability is important, but better a secure system that only a few people can use than an insecure system that everyone can use.
This is moving the goal posts. Your quoted threat model was "SIM hijacking" not an insider attack.
> Practically Signal offers little advantage over any messenger with transport encryption (e.g. Facebook Messenger): in both cases you pretty much have to trust the organisation itself.
Only if you squint enough to believe that there's no difference in what you have to trust them to do and for how long which is a stretch.
You must trust Facebook to hold on to your messages without ever choosing to look at them for any reason even though they easily could, indefinitely. If you subsequently decide this trust was misplaced, too bad, they've got all your data.
Whereas you only have to trust OWS to not have hidden some backdoor in the software they publish, which they've no incentive to do, at the point where you use the software.
If you measure two things, you can draw the "frontier" between them, sketching out the max of X that you can have while having an amount of Y. This will draw a graph where the lower left is the part you can reach, and the the upper right is the part you can't, e.g. you can't have 100% security and 100% usability.
When you are on that frontier, than the two things are in apparent opposition to each other, in the sense that you can't get more of one without having less of the other. However, if you are not on that frontier, then suddenly the conflict evaporates, because you can indeed have more of one without less of the other.
(Almost everything we ever talk about as software engineers being in "opposition" to each other is actually in this relationship. Sometimes optimality on one axis is so easy to achieve that it's still practical to discuss the two things as being in "opposition", but most of the time, before worrying about to things being in opposition it should first be checked that we are indeed on this optimality frontier. Otherwise we risk constraining our thoughts into a win/lose frame and miss the win/win options on the table.)
All of that is a lead up to my claim that the idea that GPG is on the Pareto frontier for usability and security doesn't pass the smell test. In fact it manages to have such a bad UI that it adversely impacts the security it can provide. It isn't just what git calls the "porcelain", either; some of the fundamental data structures GPG uses are just not quite right and produce fundamental confusion. It certainly doesn't help that the UI is so obscure that even a heavy user can be confused by everything that is going on.
GPG really needs a total UI overhaul, but I think this is one of those cases where the existence of an apparently "blessed" product (the GPG distribution itself) prevents anything better from being able to get enough of a foothold to succeed. If you waved a magic wand and made me the PM over the GPG product, I'd be putting out a call to the community to make a better UI, no holds barred (i.e., fundamental data structure changes are on the table and while I wouldn't necessarily want to promise a lack of backwards compatibility, don't be afraid to break it), and in a year we'll circle back around to the proposals and the GPG project itself will bless one of them. But that probably won't happen. (And I personally lack the bandwidth and the gpg street cred, so "why don't you do it" isn't a terribly practical response.)
What's the 3rd point in your triangle? I suspect it's "developer time" or "price" which boil down to the same thing depending on who's doing the measuring.
This is why almost no matter what you put on the points of the triangle, it works; as long as on the frontier there is at least some opposition, it works. The times you can have all of X and all of Y are rare, and all of three things essentially unheard of.
Skill.
Writing slow, unmaintainable code is usually a false economy. But many people just don’t know any better.
Take the refactoring Extract Variable, which is probably the simplest example. You name an intermediate value, thereby documenting it. Then hoist it out of the loop, making it faster, shorter, and clear that this value should not change.
So we're very far from perfect, but still better than most providers in this space. However, the fact that we can't easily do database migrations, debugging, etc makes our lives extremely hard, and it's much more difficult to compete in terms of UX.
Bingo. It's really easy to overlook UX, but it's the name of the game for actually improving things. Dev Experience too. There's a perverse problem in secure development, where you need to know enough to figure out why something is going wrong, but you must not leak information.
I hate this attitude. Vehemently. It's borderline ethically irresponsible to say it out loud, because it gives muggles the notion that they can save costs by reducing security, which is often simply not true.
Security is very often the cheaper option, or at least the smoother one. Certainly from an end-users' point of view, it's more convenient.
Let me list some examples:
Windows v1909 has a bunch of hardware-enfoced security turned on by default (=low admin effort), invisibly to the end user (=convenient). Older operating systems either have none of this, or it's a manual task to enable these optional features (=expensive).
A good HR automation process means that when a new employee starts, they automatically gain access to whatever they need, and nothing they don't. This is great for the user, because "everything just works" and they have everything they need available (=convenient), but it's secure because there is no error-prone manual processes to grant them access to things (=cheaper).
Windows 10 Hello for Business is essentially a virtual smart card stored in the TPM chip of your laptop, secured with a PIN or biometrics as a second factor. It uses modern cryptography and works transparently with Kerberos. It's as strong as a Smart Card but is more automatic than a password.(=convenient) It requires no hardware to deploy, and essentially eliminates a bunch of attack vectors (=cost neutral or even cheaper).
Simply enabling WSUS or leaving Windows in automatic patch mode is literally the cheapest and most secure option, yet many organisations insist on spending tons of time, effort, and money on "managing" their patches. This inevitably results in totally unnecessary paper pushing, and no measurable benefit. Meanwhile, Microsoft releases protocol-breaking changes (such as the CredSSP thing recently) in waves, with the "enabling" patch one month, and then the "enforcing" patch the next month. Smooth as silk. Except for every. Single. One. Of my customers that insisted on "managing" their patches in quarterly rollouts or whatever that had a major outage because they skipped patches.
You get the idea. There is a "happy" path of less effort, more convenience, yet very good security. Not perfect, but good enough.
Conversely, this attitude of "we must reduce security to reduce costs or improve convenience" is just insane. I've seen people go out of their way to purposefully weaken the default security of a system because of this logic.
So please. Even if you know better, just never, ever say anything like this out loud. The world is full of Muggles, and they hear this shit and do random stupid stuff that lets the Chinese government steal our hard work.
Are the policy concerns you raise related to the above, or something else?
- user checks box that says they want certs issued automatically.
- your software handles the rest.
Of course there are plenty of details for the engineers to work out, but the end user shouldn't need to know any of them.
I was thinking that you were imagining that they would need to set up some kind of internal ACME infrastructure or something. Now I see you were just imagining certbot. Maybe half the domains I've seen used aren't actually publicly resolvable. Once I saw one that was, but was actually owned by someone else.
Anyway, there is no easy way out.
There are a number of ways to cut certs internally.
Still requires a passphrase or initializing a keypair on the client & server.
> HTTPS
HTTPS requires user interaction when a site forgets to renew a certificate.
Also SSH and HTTPS don't compare well. One does client authentication, the other doesn't.
The obvious point being made is that going from SMS -> E2E should be as seamless as from telnet -> ssh.
SMS and messaging systems generally do require some level of authentication so you're making a ridiculous comparison.
And far less space to mess things up than with coding a fancy login page.
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.
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.
Quite the contrary. Unauthenticated plaintext email is a major vector for malware and phishing.
Quite the contrary, it prevents the various middle boxes we have scanning our email from scanning for malware or phishing attempts.
There are signing schemes that could help, but they'd not help much if the mail were encrypted before signing unless you're imagining client implementations wildly different than what we see today.
Is this the case with WhatsApp and Signal? Their implementations have been working great. Why can't email work the same way?
> There is plenty of evidence that actually interfering with email is in fact something that happens.
Please cite examples. I know Avast antivirus used to obnoxiously tamper with the emails sent by users in order to spam other people with its own advertising.
There are certainly targets where such attacks are relevant, but for many it's quite good.
The ratchet protocol that that approach relies on requires both ends to be online at the same time. And those implementations haven't been working great. WhatsApp was definitely compromisable by an attacker who had access to the server. I have yet to be convinced that Signal couldn't be; all the descriptions of its protocol are suspiciously ambiguous about whether the attacker is assumed to control the server or the server is trusted (since the server has to be involved in allowing offline messages to work). Furthermore we've seen nothing to suggest that the NSA isn't reading WhatsApp/Signal messages; given that those systems are tightly coupled to closed-source ecosystems (and in particular closed-source "random" sources for key generation) I suspect that serious adversaries aren't even trying to attack their cryptography directly. Contrast with PGP where we know (from Snowden's leaks) that the NSA was frustrated by their inability to break it when used properly.
> The ratchet protocol that that approach relies on requires both ends to be online at the same time.
This is simply untrue, and in fact the very point of the ratchet is to support asynchronous messaging. The next ratchet's key material is sent alongside a message encrypted with the previous ratchet-derived shared key.
> since the server has to be involved in allowing offline messages to work
Sure, for some definition of "involved". But the relay server in the Signal protocol absolutely does not need to be trusted for offline messages to work, they are end-to-end encrypted.
If you don't bother to verify the security number, then you need to trust the identity server, but that's out of scope for the protocol. Verify your security numbers!
Not true; the point of the ratchet was to allow "off the record" conversations where you would have forward secrecy, and also where the receiver would not have cryptographic proof of what you said after the conversation was ended. All of the nice security properties rely on you continuing to exchange messages regularly; it breaks down if one side sends too many messages without receiving a response from the other side, and as long as that time window is open there's a risk. In practice there's a complicated risk tradeoff around exactly how much async-ness is acceptable (both in terms of time and in terms of number of messages without a response), but any implementation will have a point at which it reverts to following protocol for sending the first message to a currently-offline user.
> But the relay server in the Signal protocol absolutely does not need to be trusted for offline messages to work, they are end-to-end encrypted.
Maybe. It's not clear under what circumstances the server could trick the clients into treating it as a first interaction with this user, at which point the server is involved in the key exchange process - something that signal security analyses tend to brush under the carpet.
> If you don't bother to verify the security number, then you need to trust the identity server, but that's out of scope for the protocol. Verify your security numbers!
This is kind of a double standard though. Good practice for using PGP is to use regularly-rotated subkeys and destroy them once they're out of use, at which point you don't have a forward secrecy problem. Real-world PGP users mostly don't do this, but real-world Signal users mostly don't check security numbers either. (In contrast, real-world PGP users do check key fingerprints, in my experience, because the software defaults and the web of trust system nudge them in the right direction).
I suppose it's not perfect but it's easy to use, widely deployed and enabled by default. I think it's a huge improvement over plaintext email.
Perhaps from the POV of The Valley, but I can assure you that email is alive and well elsewhere.
email will be alive forever as far as I am concerned (just a few months ago a friend of mine managed to send an actual telegram) and probably will be the major player in enterprise communications. but it had sort of reached a plateau in term of functionality.
(on this topic I am actually optimistic for JMAP to help revitalize the field)
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.
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.
PGP has an outdated and confusing UX, a broken threat model, and is extremely bad in many respects. But it does have users, and for some people and some tasks, it works better than alternatives. (My use cases: exchanging routine work email with other nerds who have it set up, share confidential documents.)
So, while we shouldn't minimize its very major problems, we shouldn't pretend that its user base does not exist and that it's not addressing at least some use cases.
Just get an email client that has PGP capability built in.
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.
That step isn't as straightforward as you might think.
Put yourself in the shoes of a complete novice. As of this writing, a Google search for {pgp email windows} returns gpg4win as the top search result, which is the tool the author used.
Otherwise, the software listed on the openpgp website (https://www.openpgp.org/software/) mostly doesn't have PGP capability "built in." In particular, both Evolution and Outlook require addons for PGP support.
Despite suffering from bad UX, the instructions the author followed are largely those present in a top-Google-searched guide (https://yanhan.github.io/posts/2017-09-27-how-to-use-gpg-to-... -- infobox result for {gpg encrypted email}). Easier methods that are harder to find or less obvious may as well not exist for a novice such as the author of this article.
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.
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?
But I have no trouble finding ones that I trust who agree with the key parts of that rant. For example https://www.schneier.com/blog/archives/2016/12/giving_up_on_..., https://blog.cryptographyengineering.com/2014/08/13/whats-ma..., https://dev.to/artis3n/encrypting-files-in-a-post-pgp-age-59... and many, many more.
Whether or not you can trust your phone doesn't change that PGP is missing nearly 30 years of what we've learned about best practices for encryption.
>Encrypting Email > >Don’t.
... which is obviously absurd. I think you might of been taken in by a troll attempt...
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.
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.
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.
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.
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)?
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.
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.
TLS is two layers of encryption. An outer layer using some form of PKI to form an encrypted pipe for the transfer of a symmetric key transfer then a more secure inner pipe based upon the symmetric key.
https://en.wikipedia.org/wiki/Transport_Layer_Security
That is vaguely straight forward to automate provided lots of agreement around various supported standards, because the client only has to communicate with a server that will automatically respond.
Email architecture is more like client-server-server-client (and that understates many edge cases), or rather peer-to-peer with a variety of decentralized servers in the middle and the clients aren't stateful applications like how web browsers are dedicated to browsing the web. An email client on one end has no idea what the various servers and remote clients will support and when they will ever respond for a variety of technical reasons.
Since email does not have TLS key exchange is manual unless both clients are on the same server and the server owns the process for establishing key exchange, session encryption to each party, and routing between each encrypted session.
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.
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.
Any website key retention is out of convention rather to ensure data access, and a convention Let's Encrypt is fast upending:
The certificate is valid for 90 days, during which renewal can take place at any time.
https://en.wikipedia.org/wiki/Let%27s_Encrypt
Key exchange is a component of PKI. You either need to know, or be able to request, a given key to validate it, or transmissions based on it.
TLS (as SSL before it) relies on certificate authorities (CAs), whose keys 1) are distributed to all major browsers and/or operating systems, and 2) which then vouch for website keys. Other mechanisms (e.g., key pinning) are also used. This model has many critics.
PGP (or Gnupg, and alternate implementation) rely, also to various degrees of general criticism, on a web of trust model, in which keys are signed by various other keys, possibly but not necessarily the user's own. Trust is ideally personally verified. It's been observed that this poses scaling issues.
Other PKI models have their own approaches to key trust. S/MIME uses CAs similarly to TLS/SSL, for key authentication, but keys themselves must still be retained, and secured, to assure future data access and integrity. SSH effectively relies on TOFU (trust on first use) or OOB (out of band) key distribution -- both of which effectively punt the process.
TLS, SSL, and SSH are all session-based (data-in-flight) protocols. PGP and S/MIME are storage-oriented, data-at-rest protocols. My initial comments apply to each.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Algor...
Yes, the Let's Encrypt certificates are valid for only 90 days.
> whose keys 1) are distributed to all major browsers and/or operating systems
Not exactly. Root certificates are widely distributed to user-agent applications but the actual website certificates are available upon request from visiting the sites. A CA is an issuing authority for certificates. Certificates are not directly a component of encryption, but serve to validate the encryption is trusted.
* https://en.wikipedia.org/wiki/Root_certificate
* https://en.wikipedia.org/wiki/Certificate_authority
* https://en.wikipedia.org/wiki/Public_key_certificate
* certificate distribution schemes - https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_comp...
https://tools.ietf.org/html/rfc8446#section-4.4.2.2
If you have information otherwise please do us both the favour of quoting the relevant language from an authoritative source directly in your reply.
You're also creating a dispute based on a claim I've not made. CA keys being "distributed to all major browsers and/or operating systems", my claim, which you quote, does not preclude other distribution mechanisms. That discussion is unnecessary here.
Your understanding, generally, seems in error.
Again: TLS sever keys have no minimum duration requirement, as the Let's Encrypt description previously cited makes explicitly clear: "renewal can take place at any time".
I never said anything like that. Web certificates are around for as long as both the website and CA are willing to service them.
I am thinking you reading something more into what I wrote than the words on the screen.
Which was my point in the first place.
A distinct difference from the case of data-at-rest.
I am thinking you reading something more into what I wrote than the words on the screen.
I disagree, but suggest the same for yourself.
The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key.
Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails.
But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.
> Or they could let their provider hold onto a copy of the private key
Then the key is no longer private. The idea of a private key is not to share or distribute it.
Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all.
Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever.
They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated.
The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with.
Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.
Brainstorms of a (mere) hobbyist:
Some might reason that that yields additional hardening to traditional TLS-enabled webmail applications.
On the other hand, that is more architectural design and work shifted away from the endpoints (and wasted, complex efforts with no added benefit if improperly implemented by the provider).
The provider can serve key escrow and still have the end-user application perform the encryption, which may or may not technically qualify. It certainly wouldn't fly without skepticism in a popular service/standard.
I haven't looked into it deeply enough to present a confident statement either way.
Email does have the equivalent of TLS, its TLS. Send a message to another user in Facebook or whatev over the web and its secured by TLS over the wire, but does not protect from the server reading it. Send a email to user on an email server and its secured by TLS over the wire, but does not protect the server from reading it. Exactly the same thing.
So this confuses a few things. Technically you are right in that TLS applies to the transport layer (layer 4) while both web and email are application layer (layer 7), but then the question is how to apply it for email in practice that differs from manual key exchange?
Web mail uses web (port 80 or 443) to communicate to a web server email application where the email is blasted out as regular email (most likely as SMTP over port 25). Since the first leg is regular web traffic regular web rules apply, but only to that first leg. Applications like Outlook and Thunderbird are not webmail and do not use web traffic to send/receive email.
It's probably easiest to see what's actually going on the TLS 1.3 design - even though this is effectively what really happens in popular clients and servers with older TLS versions today also - because in TLS 1.3 none of it's optional any more.
In TLS 1.3 the peers agree an ephemeral shared "master" secret using an elliptic curve variant of the Diffie Hellman algorithm and random data they've chosen. ECDHE means each side ends up knowing the same essentially random secret and nobody else knows what that is, even if they eavesdropped on everything both peers said.
Then this shared secret is enough to generate a number of symmetric keys used to secure all subsequent communications between the peers with conventional symmetric encryption (often AES using the GCM cipher mode).
Now, the two peers can communicate securely, it is impossible for anyone to eavesdrop. But, at this stage neither is sure who the other is. It is conventional (in web browsers) for the client's identity to remain unknown in TLS but the server proves its identity using a signature algorithm. Specifically it signs a transcript of the process so far, proving that it took part in the sequence of events that led to this point, using a key for which it presents a certificate. The client can examine the certificate and signature and verify that the certificate is trustworthy and that the transcript signature proves that the certificate's subject is the server it is talking to.
There aren't two pipes, one contained within the other. There's just one pipe, a secure pipe between client and server, and then that pipe is used to transport proof of the server's identity (and optionally, likewise for the client). Without that identity the pipe is still secure, you just don't know who it is you're talking to securely.
Those pipes are the asymmetric handshake to exchange the shared secret and the symmetric encryption provided by that shared secret.
Certificates do not provide encryption and thus are not a “pipe”. Certificates are used to prove the identity of one of the end points (the server).
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.
Then, and only then, your phrase will be false.
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).
Use keybase. It's easier!
[1] https://arstechnica.com/information-technology/2016/12/op-ed... [2] https://arstechnica.com/information-technology/2016/12/signa...
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.
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.
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...
https://riseup.net/en/security/message-security
FSF is a bit more to the point for the casual user:
* https://emailselfdefense.fsf.org/en/
It is not always clear to the casual user if they are using gpg1 or gpg2. You pretty much always want to use gpg2. This is a genuine issue with the gpg ecosystem.
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?
job done, assuming you want to transmit files under 100 MB/message.
Not to mention even Glenn Greenwald did not expend the effort to learn GnuPG, even when Snowden sent him a 10 minute tutorial.
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".
Highly recommend for personal use.
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.
Most have shutdown their free products in the past few years, I suspect as a result of having to invest money in their decades-old web applications that no longer function correctly in modern browsers.
One remains, but this blog post warns that they practice unsafe private key practices, so I'm inclined to suggest that none do.
https://davidroessli.com/logs/2019/09/free-smime-certificate...
(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.)
I don't think they ever really took off (or even existed), and there isn't anything in the Baseline Requirements / EV Guidelines as far as I know.
Nowadays they seem to be a bit of a myth, as there is very little evidence of them online except for use in code signing.
The problem is, nothing stops anybody else creating such a CA. Why should I trust either of them? Why should anybody? Unless a critical mass trust the same CAs it's hopeless.
What you need there is a PKI, a Public Key Infrastructure. A PKI has two components, firstly some technical agreements like what sort of certificates are used, how to write email addresses and so on, for which you can mostly rely upon PKIX in this scenario - but then you also need some consensus on the much more difficult and political trust problem.
Mostly what happens is that PKIs are relatively small and private. EMV ("Chip and PIN" cards) has its own private PKI managed by EMVCo, the RIRs have one for route management called RPKI, lots of businesses have their own. Apple and Microsoft operate PKIs for "code signing" of various sorts.
And there's one obvious public PKI, the Web PKI, which is why your browser agrees with mine that this is https://news.ycombinator.com/
But there isn't one for email. So the far trickier problem than spinning up some "LetsEncrypt like service for personal certificates" is building that PKI.
It's strange to me that any tool that simply encrypts email requires a CA-signed certificate instead of a simple public key or a self-signed certificate. Self-signing is totally okay provided you have a way to distribute your certificate that allows the recipient to authenticate that it came from you. Then they can simply add your certificate to their list of trusted certificates.
Yes in the broad sense and no in the specific case.
In order to activate macOS Mail encryption you need a certificate on your keychain. So by having a CA issue you a certificate, the mail client can generate the keys to encrypt that mail without additional passwords (e.g., relying on in-situ authentication). So in this application they are interrelated.
The point is about making encrypted email easier. PGP is not the answer, its tools are awful as stated in OP. SMIME can be the answer, but the paucity of CA for personal certs is an issue. That is what we are discussing in this thread.
The problem is that it isn't completely automated and default in some email clients. Why would CA issue personal certificates? It defeats the purpose of having default CA certificates, and is the same as trusting a government agency to manage digital IDs without transparency. Might as well create your own which you can trust. Look into Keybase if you want something more automated.
Disagree on both counts, and I'm not one of those Signal zealots or an "email-is-deprecated" hipster.
Suppose you want to use gpg to encrypt Gmail conversations. Your workflow is basically copy-pasting text into and out of a text editor and then attaching the ciphertext to the email and sending it.
Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner.
If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable.
If you're using the web browser. Gmail can use IMAP and so plenty of clients can encrypt the messages natively. There are Android apps (and probably IOS) that do this as well automatically.
The important thing here is that Gmail isn't the standard for email, and the more that you rely on commercial email companies to streamline encryption the more you'll be let down.
> Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner.
GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc. The documentation is available on their website and follows industry standards in documentation, and also including man pages as well.
There is always improvements that can be made in terms of automation for users, but that is what Keybase does. There are also a plethora of third-party GPG tools that a large community of users are happy with and there is nothing stopping you from building your own.
> If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable.
Can't you say the same about almost any piece of software. If you tried to understand the internals of almost any piece of software, it can be difficult to understand. Vim has its own scripting language. JavaScript has like 20 different implementations.
That is what the third-party tools are for, and many of them have made it very easy to use.
Sure, I know that. And you know that. How many muggles know that? The argument can't be "switch to mutt" or something along those lines. Even Thunderbird does not to the best of my knowledge run on mobile, today's premier platform. You can't win people over that way.
>GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc.
I think it's pretty obvious I meant the command line tools. They most certainly have a UX and a UI. Painful ones.
>Can't you say the same about almost any piece of software.
Absolutely not. Unlike gpg, successful software doesn't require you to understand its internals to operate successfully. How many people use Windows? Android? iOS? What percentage of those users really understand the internals?
No one said switch to Mutt. There are multitude of quality email software for both mobile and desktop, including webmail frontends to IMAP. In fact, you can even configure Dovecot with virtual folders to work like Gmail, and there are multiple frontends and even enterprise Helm charts for email servers that also include ActiveSync to work with calendar integration and contacts.
> I think it's pretty obvious I meant the command line tools. They most certainly have a UX and a UI. Painful ones.
How painful can a CLI be to you? If you want encryption for your grandma, then automate the deployment of the software and configuration for your grandma. There are multiple email apps on Android alone that make setting up encryption easy. If you thing GPG UI is painful, then you should look at the rest of the Linux and Go Lang CLI ecosystem. They are all the same, and for what it is GnuPG does a great job at it and for developers and CLI-inclined individuals it works well and is easy to understand.
> Absolutely not. Unlike gpg, successful software doesn't require you to understand its internals to operate successfully. How many people use Windows? Android? iOS? What percentage of those users really understand the internals?
Again, you'd probably be better off not trying to with GPG and just using Thunderbird or installing an Android app with encryption. It sounds like you have no interest in configuring anything more complex or working on solutions to these problems without trying to complain about GPG which isn't the problem at all:
https://support.mozilla.org/en-US/kb/digitally-signing-and-e...
I'm telling you why normies don't adopt encrypted email (the tooling is fiddly, confusing and hard to use) and you're coming back at me with stuff like "configure dovecot to use virtual folders" which is not something most email users can do.
>Again, you'd probably be better off not trying to with GPG and just using Thunderbird or installing an Android app with encryption. It sounds like you have no interest in configuring anything more complex or working on solutions to these problems without trying to complain about GPG which isn't the problem at all:
A majority of people will not use Thunderbird because more and more people don't use computers any more. Their phones or tablets are their primary computing devices. Thunderbird is not a solution. And there really aren't many good free email apps out there (remember, you're competing with free because a lot of these people are on Gmail already). The biggest alternative mail client for Android in terms of recommendation tends to be K9 mail which on my OnePlus 3 and my Pixel 3 simply did not work at all.
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
Isn't this kind of a modern version?
As well as :
This is why I have two Yubikeys.
But are you suggesting soft tokens (only) are useless?
That's not a great analogy because removing a physical letter from your mailbox and opening the envelope leaves physical evidence of tampering. It's also a felony, with a disproportionately severe punishment, if you're not the designated recipient of the letter. Reading an email at rest on a server somewhere leaves no evidence that the content was leaked and is unlikely to be punished. In the absence of physical evidence when a message is intercepted, or practical recourse when the privacy of the communication is violated, I for one would very much prefer option #1—end to end encryption. Frankly if there were a system as easy as GPG for end to end encryption of physical letters, I'd prefer that as well.
GPG does clearly have UX issues. The manually curated web-of-trust was a good idea in principle but too much work to really catch on at scale. Encryption needs to be enabled not only by default but unconditionally, with transparent key exchange and some form of automatic, distributed reputation tracking. The system that fixes these issues probably won't be built on top of SMTP or interoperate with existing email clients, if only because encrypted email cannot be made mandatory without breaking compatibility anyway, but it will serve the same function of facilitating asynchronous, long-form written communication.
While I understand that in an ideal world, #1 would be perfect — in today's real world, #2 would be better than the often-unencrypted mess we have today. I've seen a lot of personal mail servers that no one set up encrypted SMTP on, and yet their owners have GPG keys published and signed. Transport encryption and end-to-end encryption are not conflicting goals.
I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". I'm not interested in building an encrypted utopia that doesn't interoperate with email. Every social network and web forum for the past 20 years has tried to do this, and none of them have replaced email at all.
I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. It's not a big ask, and it doesn't prevent GPG from succeeding.
But it might have prevented some random person who probably doesn't need ciphertext encryption from wanting to use GPG if they'd realized that option #2 was in place for them, and thus prevented this entire article's UX nightmare at all.
On that we agree. It's better to have both. Even if you already have end-to-end encryption for the content, transport encryption helps to avoid leaking metadata about who the message is being delivered to.
> I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway".
Whether you accept it or not, if you reject unencrypted messages, or insist on only sending encrypted messages, then you aren't interoperable with today's email system. That's not a defeatist view, it's just being realistic. And as we've seen with GPG, if you don't insist on encrypting everything then encryption will not be used—or worse, it will be used inconsistently, as in the case of someone sending an unencrypted reply which quotes an encrypted message.
> I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption.
Plain email can be improved somewhat but it's still essentially the same as writing your message on a postcard. Transport encryption is akin to physical custody of the mail; it's useful but not sufficient. The only people who would see your postcard while it's in transit are postal workers, and yet people still use envelopes to keep their messages private from the people handling the mail. Transport encryption does nothing to help in that area and does not fulfill the expectations that people have in regard to postal mail, which are based in large part on legal codes and physical properties which do not apply to email. To get something similar to a message in an envelope the content must be encrypted end to end, not just at the transport layer.