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.
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.
>...the PGP fanbase sees their 6 levels of trust as Zimmerman dogma that must not be altered under pressure of earthly realities, or security insights developed after the Code was written down.
I am an actual OpenPGP shill who is entirely in favour of a very conservative approach to the standard but I really don't see the problem here. Autocrypt is a separate standard. Clients can implement it completely and just switch the trust to OpenPGP if a PGP identity shows up. There is nothing wrong with a client adding some extra trust information to accommodate autocrypt.
Autocrypt requires its own separate PGP contacts database (regular PGP standard doesn't allow automatic key overwrites), and as such most MUAs prefer to limit the number of things they support to old PGP. This is a problem for adoption.
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.
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...
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"
Honestly, this makes me appreciate Signal all the more – it seems the only barrier is getting friends to adopt it, but if used by an organization could it be an alternative to E2EE email?
In my experience, the client is stupidly buggy. I've lost messages silently multiple times. This is a known issue and after losing several key messages stopped using it.
it probably should be mentioned that the first github issue you linked is about signal loosing SMS-messages, not signal-messages. so for the case mentioned by the parent (" getting friends to adopt it") it is not really relevant.
One thing I've been able to tell friends is to just replace their default SMS app with Signal, since they're not particularly attached to that app anyway. Then, at least their messages to me will then be encrypted, and every additional person I get to install Signal will have an additional contact being able to use it/join a group.
This works until they either switch back to their original app or get a new phone and don't install signal on it. If you stop using Signal you need to deregister your phone number from the service, but many people don't know or care to do that.
If they don't, anyone who has ever used Signal to communicate with them will be silently unable to contact them anymore.
True. The former hasn't been a problem for me, the latter's becoming increasingly less so now that more and more people have switched, and people are starting to more consciously use it every now and then for one of the few Signal groups we have - but it certainly was a problem at first.
I use it both on iOS and macOS and it’s become substantially better in the last year or so, especially in terms of the two clients syncing with each other.
That's just my opinion, but to me E2EE from Whatsapp/Signal/Telegram is just Marketing. The trust is worse than Trust on first use (TOFU) since it can change repeatedly, most people install it through the Play Store so one might argue that it is in a certain sense as secure as closed-source software and the whole key exchange is hidden from the user. Not to mention that most Smartphones are blackboxes to a large part and phone number based apps are vulnerable to sim hijacking (yes we see when the key changes, but nobody cares and it's difficult to reestablish the trust).
Probably depends on the use-case, but as a normal user that lives in a non-repressive state, there is little value in using Signal. (FWIW Signal uses central servers, so in a repressive state it can just be turned off?) GPG based security is superior and not tied to a blackbox platform...
"[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.
> "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.
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.
> 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.
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.
> With transport encryption you have to trust that the infrastructure is secured on an ongoing basis.
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.
> But it's only OWS that control that check, right?
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.
Could you please explain to me why Signal is the superior messaging platform?
I can't understand why it requires ID/passport from you to use it. I guess if you want to use an encrypted messaging platform then you don't want it to be tied to the government issued ID.
p.s. you phone number is tied you your ID, so it's basically your ID
It sounds like you are worried about a threat model (being identified by your government) that Signal is not designed to, nor attempts to address. There are some workarounds that may satisfy your needs, such as using a different phone number provided by Google Voice or Twilio.[0]
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.
In comparison to what other messaging platforms? What do you mean it requires ID/passport? It uses phone number as a "username", which is why it's easy to use.
Some countries require ID/passport to just get a phone number. This could potentially be sidestepped by getting a Twilio number or Google Voice number, but that causes it to be far from frictionless.
Unless if ISP positions itself as rigid security service devoted to provide you security features and some famous people recommend using it in order to transfer sensitive documents.
Public internet access, both in the form of hotspots and computers, are perfectly usable (if not terribly secure). But you cannot use Signal with a payphone.
That's a leap, from 'some security' to 'absolutely zero inconvenience'. There's no middle ground? Don't we all use passwords now for many things? That's not zero attention needed.
Often the mentality you will find is "any hole is a hole that will be exploited", so they make these incredibly difficult systems with perfect security that nobody ever uses because they're so hard to use.
SSH is flawed in that you have to trust the host the first time you connect to it. For most people this is a reasonable tradeoff, but for security nerds it can be an impossible barrier to adoption. This is why some SSH servers spit out big long hexcodes or weird picture things, you are supposed to securely message the owner of the server to verify it before you accept it. Details are of course left up to the user because any default system you set up will of course be exploited. It's head of line security exploits all the way down.
Password managers have turned this into near-zero inconvenience: when I arrive at the login page my UID and PW are already filled in.
(I also have three hard tokens for from banks and investments, two ubikeys (both for LastPass, one in storage), and google authenticator on my iphone for anyone that offers it... so I've taken a step backward for added security.)
I think for most people, they're trading less convenience (manually dealing with passwords, and the randomly changing rules and resets different places use) for more convenience (autofill, managed & synced)
Sure, but people with PW managers are reducing their long-term inconvenience by paying a little bit up front. I don't use a PW manager for any security benefit but because it makes it easier to sign into things.
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.
I keep my passwords in my head because I can't put up with managing a dozen different authentication schemes, any one of which could be compromised or lost at the worst possible time.
My interpretation of the parent post was not that there is no middle ground, but that if a user can use a service without engaging in an extra step to increase security, they will do so, no matter how easy the extra step is. Passwords are not an extra step - they are required.
Counterpoint: I work for a company that sells software to mostly big companies. Sometimes they want to host it themselves. Creating valid certificates usable for HTTPS is a never-ending support issue.
My working theory is that the Venn diagram of organizations self-hosting software on an intranet with private DNS and organizations that don't have an internal CA is almost entirely disjoint.
Are the policy concerns you raise related to the above, or something else?
The ones that are self-hosting are more-or-less doing it specifically so that they can use non-publicly-accessible servers. So I guess that won't work.
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.
We're developing an electronic health record platform that stores data encrypted in a way that we don't have the decryption key. We don't have end-to-end encryption, but if you got a database dump then it'd be quite tricky to decrypt what's in it as data belonging to a person can be unlocked with a secret that the person has, and we don't; only in memory when serving the user.
So we're very far from perfect, but still better than most providers in this space. However, the fact that we can't easily do database migrations, debugging, etc makes our lives extremely hard, and it's much more difficult to compete in terms of UX.
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.)
If I say "Public private key cryptography" it is like music to my ears. The term is near poetic. The experience is so hard to explain I think I have to make a drawing.
These things usually form triangles with "cheap, good, fast: pick any two" being the canonical case.
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.
We are essentially talking about situations where variables are partly independent, and here you are trying to bring everything back to a zero sum game already. I shouldn’t be responding at all, but ok, I’ll bite.
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.
Triangles are just a convenient way to frame the three-dimensional relationship. Theoretically you can take it to any number of dimensions with fairly obvious extensions to the definition; however, it starts to become computationally expensive and human-impractical to gain much understanding that way.
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.
> Making better security less and less inconvenient is the name of the game.
Bingo. It's really easy to overlook UX, but it's the name of the game for actually improving things. Dev Experience too. There's a perverse problem in secure development, where you need to know enough to figure out why something is going wrong, but you must not leak information.
> 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.
> security is almost ALWAYS at odds with convenience.
I hate this attitude. Vehemently. It's borderline ethically irresponsible to say it out loud, because it gives muggles the notion that they can save costs by reducing security, which is often simply not true.
Security is very often the cheaper option, or at least the smoother one. Certainly from an end-users' point of view, it's more convenient.
Let me list some examples:
Windows v1909 has a bunch of hardware-enfoced security turned on by default (=low admin effort), invisibly to the end user (=convenient). Older operating systems either have none of this, or it's a manual task to enable these optional features (=expensive).
A good HR automation process means that when a new employee starts, they automatically gain access to whatever they need, and nothing they don't. This is great for the user, because "everything just works" and they have everything they need available (=convenient), but it's secure because there is no error-prone manual processes to grant them access to things (=cheaper).
Windows 10 Hello for Business is essentially a virtual smart card stored in the TPM chip of your laptop, secured with a PIN or biometrics as a second factor. It uses modern cryptography and works transparently with Kerberos. It's as strong as a Smart Card but is more automatic than a password.(=convenient) It requires no hardware to deploy, and essentially eliminates a bunch of attack vectors (=cost neutral or even cheaper).
Simply enabling WSUS or leaving Windows in automatic patch mode is literally the cheapest and most secure option, yet many organisations insist on spending tons of time, effort, and money on "managing" their patches. This inevitably results in totally unnecessary paper pushing, and no measurable benefit. Meanwhile, Microsoft releases protocol-breaking changes (such as the CredSSP thing recently) in waves, with the "enabling" patch one month, and then the "enforcing" patch the next month. Smooth as silk. Except for every. Single. One. Of my customers that insisted on "managing" their patches in quarterly rollouts or whatever that had a major outage because they skipped patches.
You get the idea. There is a "happy" path of less effort, more convenience, yet very good security. Not perfect, but good enough.
Conversely, this attitude of "we must reduce security to reduce costs or improve convenience" is just insane. I've seen people go out of their way to purposefully weaken the default security of a system because of this logic.
So please. Even if you know better, just never, ever say anything like this out loud. The world is full of Muggles, and they hear this shit and do random stupid stuff that lets the Chinese government steal our hard work.
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.
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.
> End-to-end encryption is still a very challenging problem almost everywhere except for direct connection server-side TLS.
Is this the case with WhatsApp and Signal? Their implementations have been working great. Why can't email work the same way?
> There is plenty of evidence that actually interfering with email is in fact something that happens.
Please cite examples. I know Avast antivirus used to obnoxiously tamper with the emails sent by users in order to spam other people with its own advertising.
> Is this the case with WhatsApp and Signal? Their implementations have been working great. Why can't email work the same way?
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.
FUD. There are several critical flaws in your analysis (disclaimer: I'm an enthusiast, not a cryptographer).
> 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!
> 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.
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).
WhatsApp has been blocked in my country several times by judges for failure to disclose message content during investigations. This suggests there was no way to intercept this stuff at least at that point in time. Maybe the NSA has found a way but I seriously doubt they're going to share it with other government agencies.
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.
WhatsApp is probably secure against anyone who doesn't have access to its owners (Facebook) or the mobile OS makers. But much the same is true for any encrypted messenger. Plaintext email is not the competition.
WhatsApp and Signal require the user to verify some identity numbers to prevent MITM attacks. No one does that. If you are OK with that level of protection then everything gets easy, even email encryption.
It works a little better - it tells me when "the security code" changes. Thus an unnoticed mitm attack has to begin at the beginning of the conversation or at a plausible change of the device. The attacker must be ready to intercept the "you got a new phone? Which one did you get? How broke the previous one?" and keep the conversation plausible.
There are certainly targets where such attacks are relevant, but for many it's quite good.
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.
Encryption does not do a thing to prevent malware or 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.
Alas, in some places communications security and anonymity is a ‘black swan’ problem in that it's barely noticeable most of the time, but someday it might irreparably mess up one's life. So of course people are split into those who may occasionally think that it'd be nice to have encrypted messaging, and those who heard of the consequences and now worry about them like it's plague.
Are these sort of leaks usually from intercepting email? or some other method like, from a trusted participant in the conversation leaking them, a backup being found, the machine itself being compromised?
That is sadly related to the fact that email as a platform is pretty much dead outside small niches. Very few applications are built on top of email. Of course that is also chicken and egg problem; without good security story its bit difficult to build anything on it these days.
but it is not in anything close to a growth in many senses.
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)
There is a key area where mail is central: The "I lost my password" feature of websites. Apple ID, Google+ (or whatever they call it now) and Facebook login replace it to some degree (especially on mobile device apps) but for far most websites newly created passwords or activation links are sent via regular mail unprotected.
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.
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.
It's not true that something isn't valuable just because it hasn't scaled.
PGP has an outdated and confusing UX, a broken threat model, and is extremely bad in many respects. But it does have users, and for some people and some tasks, it works better than alternatives. (My use cases: exchanging routine work email with other nerds who have it set up, share confidential documents.)
So, while we shouldn't minimize its very major problems, we shouldn't pretend that its user base does not exist and that it's not addressing at least some use cases.
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.
> Just get an email client that has PGP capability built in.
That step isn't as straightforward as you might think.
Put yourself in the shoes of a complete novice. As of this writing, a Google search for {pgp email windows} returns gpg4win as the top search result, which is the tool the author used.
Otherwise, the software listed on the openpgp website (https://www.openpgp.org/software/) mostly doesn't have PGP capability "built in." In particular, both Evolution and Outlook require addons for PGP support.
Despite suffering from bad UX, the instructions the author followed are largely those present in a top-Google-searched guide (https://yanhan.github.io/posts/2017-09-27-how-to-use-gpg-to-... -- infobox result for {gpg encrypted email}). Easier methods that are harder to find or less obvious may as well not exist for a novice such as the author of this article.
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.
I really enjoy articles like these because it offers a perspective that is difficult for developers of software to see themselves. Say you're starting a company that provides a technical service and you claim on your homepage "3-click install!" Rarely it's ever just 3 clicks. It's a good idea to watch videos or read written stories of every step a user takes in order to use your service, including learning how to use it and their mistakes.
> Each public key must be signed before messages from the owner of that public key can be decrypted.
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.
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.
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.
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.
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)?
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.
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.
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.
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.
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.
Another issue with encryption is the other aspect of security; malware detection. Since E2E encryption happens at the MUA level, and most spam/phishing/malware scanning is done either at the MTA level or by a gateway, detection becomes almost impossible. MUA would need to do all the extra heavily lifting. Email was designed as a plain-text messaging system. PGP, MIME and S/MIME are extensions to this, but fundamentally, email is still plain text. The key to secure email is not to use email for secure things.
Encryption on the web is easy, because its automated by TLS. A far more concise answer is that email does not have an equivalent to TLS because it's architecture is not the simple client-server model like the web.
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.
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.
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.
Your layered model with "pipes" seems like a confusion and is misleading at best.
It's probably easiest to see what's actually going on the TLS 1.3 design - even though this is effectively what really happens in popular clients and servers with older TLS versions today also - because in TLS 1.3 none of it's optional any more.
In TLS 1.3 the peers agree an ephemeral shared "master" secret using an elliptic curve variant of the Diffie Hellman algorithm and random data they've chosen. ECDHE means each side ends up knowing the same essentially random secret and nobody else knows what that is, even if they eavesdropped on everything both peers said.
Then this shared secret is enough to generate a number of symmetric keys used to secure all subsequent communications between the peers with conventional symmetric encryption (often AES using the GCM cipher mode).
Now, the two peers can communicate securely, it is impossible for anyone to eavesdrop. But, at this stage neither is sure who the other is. It is conventional (in web browsers) for the client's identity to remain unknown in TLS but the server proves its identity using a signature algorithm. Specifically it signs a transcript of the process so far, proving that it took part in the sequence of events that led to this point, using a key for which it presents a certificate. The client can examine the certificate and signature and verify that the certificate is trustworthy and that the transcript signature proves that the certificate's subject is the server it is talking to.
There aren't two pipes, one contained within the other. There's just one pipe, a secure pipe between client and server, and then that pipe is used to transport proof of the server's identity (and optionally, likewise for the client). Without that identity the pipe is still secure, you just don't know who it is you're talking to securely.
Those two "pipes" you're talking about aren't one inside the other, the key agreement just takes place sequentially before the key is used because of casuality.
I am a layperson, so the answer is probably painfully obvious, but why can't e-mail have TLS-style key exchange, where the sender's server gets the public key from the recipient's server and encrypts the message with it before sending it over?
The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key.
Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails.
But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.
You could, but you're dropping the qualification of end-to-end encryption.
Brainstorms of a (mere) hobbyist:
Some might reason that that yields additional hardening to traditional TLS-enabled webmail applications.
On the other hand, that is more architectural design and work shifted away from the endpoints (and wasted, complex efforts with no added benefit if improperly implemented by the provider).
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.
Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request?
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.
> Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request?
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.
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.
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.
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.
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.
Again, there's nothing in the Wikipedia link which specifies that site certificates MUST exist for a specific duration. Because there's no such requirement in RFC 8446 4.4.2.2, "Server Certificate Selection":
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".
CAs generally issue certificates to websites for 1 or 2 years, but there isn't a fixed duration imposed by cryptography standards. Sometimes the certificates are rejected prematurely due to compromise, and there is a process for that called key revocation.
I am thinking you reading something more into what I wrote than the words on the screen.
Best practice is Let's Encrypt 3 month certs and best practice is to only allow TLS cipher suites that provide PFS (which are the only ones allowed for HTTP/2 and the only ones present in TLS1.3), which mean that the private key for the cert is useless as soon as the cert expires and cannot be used for retroactive decryption even while the cert is valid.
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.
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.
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.
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.
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.
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).
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.
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.
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...
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.
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?
>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.
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".
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.
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.
CA certificate signing is orthogonal to encryption. If you only need to encrypt an email then a public key is sufficient. However if you also need a proof that you are who you say you are, then you would need a certificate that is authenticated by your PKI plus a public encryption key.
It's strange to me that any tool that simply encrypts email requires a CA-signed certificate instead of a simple public key or a self-signed certificate. Self-signing is totally okay provided you have a way to distribute your certificate that allows the recipient to authenticate that it came from you. Then they can simply add your certificate to their list of trusted certificates.
> CA certificate signing is orthogonal to encryption.
Yes in the broad sense and no in the specific case.
In order to activate macOS Mail encryption you need a certificate on your keychain. So by having a CA issue you a certificate, the mail client can generate the keys to encrypt that mail without additional passwords (e.g., relying on in-situ authentication). So in this application they are interrelated.
Because that brings us to square one again, which is the article. You need a CA, PGP/GPG construct their own federated "CA" like entity, but its the same thing.
You don't need a CA for PGP/GPG. In fact, it is generally advisable to never trust a CA for public keys. However, it is common to utilize the fingerprint to verify the key from a public server that has been provided by the user. Ideally though, you'd never trust an email provider to maintain a CA of keys that you'd actually use to send a confidential message.
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.
There is nothing awful about PGP. The tools are more than sufficient. GPG is industry standard for encryption and signing. It is used with Git. There are entire password managers built with it.
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.
>There is nothing awful about PGP. The tools are more than sufficient.
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.
> 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.
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.
>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.
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?
> 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.
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:
Okay, one of us simply doesn't understand what the other is saying.
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.
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.
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.
"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.)
In principle nothing stops you creating such a CA.
The problem is, nothing stops anybody else creating such a CA. Why should I trust either of them? Why should anybody? Unless a critical mass trust the same CAs it's hopeless.
What you need there is a PKI, a Public Key Infrastructure. A PKI has two components, firstly some technical agreements like what sort of certificates are used, how to write email addresses and so on, for which you can mostly rely upon PKIX in this scenario - but then you also need some consensus on the much more difficult and political trust problem.
Mostly what happens is that PKIs are relatively small and private. EMV ("Chip and PIN" cards) has its own private PKI managed by EMVCo, the RIRs have one for route management called RPKI, lots of businesses have their own. Apple and Microsoft operate PKIs for "code signing" of various sorts.
And there's one obvious public PKI, the Web PKI, which is why your browser agrees with mine that this is https://news.ycombinator.com/
But there isn't one for email. So the far trickier problem than spinning up some "LetsEncrypt like service for personal certificates" is building that PKI.
I remember reading about Individual Validation (IV) certificates, which I believe were similar to Extended Validation (EV) certificates, but for individuals.
I don't think they ever really took off (or even existed), and there isn't anything in the Baseline Requirements / EV Guidelines as far as I know.
Nowadays they seem to be a bit of a myth, as there is very little evidence of them online except for use in code signing.
I had to spend some time searching myself. I used to use Comodo's free certs back when they were still called Comodo. All these changes seem to have made things difficult.
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.
> 2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it.
That's not a great analogy because removing a physical letter from your mailbox and opening the envelope leaves physical evidence of tampering. It's also a felony, with a disproportionately severe punishment, if you're not the designated recipient of the letter. Reading an email at rest on a server somewhere leaves no evidence that the content was leaked and is unlikely to be punished. In the absence of physical evidence when a message is intercepted, or practical recourse when the privacy of the communication is violated, I for one would very much prefer option #1—end to end encryption. Frankly if there were a system as easy as GPG for end to end encryption of physical letters, I'd prefer that as well.
GPG does clearly have UX issues. The manually curated web-of-trust was a good idea in principle but too much work to really catch on at scale. Encryption needs to be enabled not only by default but unconditionally, with transparent key exchange and some form of automatic, distributed reputation tracking. The system that fixes these issues probably won't be built on top of SMTP or interoperate with existing email clients, if only because encrypted email cannot be made mandatory without breaking compatibility anyway, but it will serve the same function of facilitating asynchronous, long-form written communication.
It's enough of an analogy to make the point, though. Most people's needs for letters security are option #2, not option #1. If you can get the email from source SMTP server to destination mailbox encrypted over the wire, then most people don't care if someone could possibly look at it in your mailbox. And, very few people mind that the "lost letters" division of the postal service opens their mail and packages to try and return it to them when something goes wrong.
While I understand that in an ideal world, #1 would be perfect — in today's real world, #2 would be better than the often-unencrypted mess we have today. I've seen a lot of personal mail servers that no one set up encrypted SMTP on, and yet their owners have GPG keys published and signed. Transport encryption and end-to-end encryption are not conflicting goals.
I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". I'm not interested in building an encrypted utopia that doesn't interoperate with email. Every social network and web forum for the past 20 years has tried to do this, and none of them have replaced email at all.
I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. It's not a big ask, and it doesn't prevent GPG from succeeding.
But it might have prevented some random person who probably doesn't need ciphertext encryption from wanting to use GPG if they'd realized that option #2 was in place for them, and thus prevented this entire article's UX nightmare at all.
> Transport encryption and end-to-end encryption are not conflicting goals.
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.
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).
> 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).
This is why I have two Yubikeys.
But are you suggesting soft tokens (only) are useless?
