Privacy in email communication: we should use encryption by default(notes.nicfab.it)
notes.nicfab.it
Privacy in email communication: we should use encryption by default
https://notes.nicfab.it/en/posts/privacycom/
152 comments
Just use the browser dev tools to re-enable text selection? There must be a browser extension that can automate that too. Maybe even Greasemonkey would do.
In Firefox, you can simply set a preference and scripts won't be able to disable copy/paste.
Go to about:config, and search for dom.event.clipboardevents.enabled and disable it.
Go to about:config, and search for dom.event.clipboardevents.enabled and disable it.
This will probably break many other use cases as well (e.g. services that allow pasting formatted text and will convert it to unformatted text, or pages like GitHub where you can paste an image into the edit area).
It shouldn't break either of those usecases (I gave GitHub a go and it certainly seems to work). Those functions tend to be handled by a different preference (dom.allow_cut_copy).
The only service I am aware of that it does break is Google Docs, because they handle things in an odd manner. But as they received several bug reports for that since 2017, I wouldn't get your hopes up that it'll ever be fixed.
The only service I am aware of that it does break is Google Docs, because they handle things in an odd manner. But as they received several bug reports for that since 2017, I wouldn't get your hopes up that it'll ever be fixed.
That’s exactly what I do, however I wouldn’t want to try and explain how to do it to my Parents. They are meticulous with their filing system and this would make it impossible. They would ultimately probably print more stuff out to save.
Unfortunately, Rights Management is the hot thing of the minute. It doesn't make since for you since you are the ultimate destination, but in many cases we need to transmit information and also take steps to ensure that the recipient does not forward that data anywhere else without our permission. If we are going to still be responsible for the data's privacy after it leaves our network then we are just going to never let it leave our network.
These unfriendly encryption mechanisms also let us actually retract a message if it was sent to the wrong person, a feature that is on the honor system in traditional implementations.
On the user end all they know is that if they put [encrypt] in the subject they won't be written up by their compliance department. People really like not getting fired over clerical stuff so they over-use it.
These unfriendly encryption mechanisms also let us actually retract a message if it was sent to the wrong person, a feature that is on the honor system in traditional implementations.
On the user end all they know is that if they put [encrypt] in the subject they won't be written up by their compliance department. People really like not getting fired over clerical stuff so they over-use it.
So, I understand the motivation, it's the misguided implementation that's the problem. The only thing from your suggested requirements that actually works is the ability to "retract" an email before its been read.
It can still be forwarded (after extracting from a badly implemented site). The "ensure the right person got it" password is stupid as its literally sending it to the same email address.
The thing I find so bizarre about this is that lawyers/accountant etc. have been seeing out letters in the post forever and never had the desire to implement this level of security. Post can be intercepted, read by third parties and modified at will, just like unencrypted email. The only thing that's changed is that because there is supposedly the ability to do it someone has lobbied for there to be a mandate for it.
Just because it "can be done" doesn't mean is should or that it achieves what the motivation was.
If there is something that important that it can't be in the wrong hands then either do it in person or sent a courier with the signed for letter that requires id on delivery.
These systems are nothing other than security theatre that's sold to the unknowledgeable as something they need, when the reality is it's a complete waste of everyones time. (except for the person selling it!)
It can still be forwarded (after extracting from a badly implemented site). The "ensure the right person got it" password is stupid as its literally sending it to the same email address.
The thing I find so bizarre about this is that lawyers/accountant etc. have been seeing out letters in the post forever and never had the desire to implement this level of security. Post can be intercepted, read by third parties and modified at will, just like unencrypted email. The only thing that's changed is that because there is supposedly the ability to do it someone has lobbied for there to be a mandate for it.
Just because it "can be done" doesn't mean is should or that it achieves what the motivation was.
If there is something that important that it can't be in the wrong hands then either do it in person or sent a courier with the signed for letter that requires id on delivery.
These systems are nothing other than security theatre that's sold to the unknowledgeable as something they need, when the reality is it's a complete waste of everyones time. (except for the person selling it!)
It would be extremely expensive to mechanize the dragnet stealing/modification of the post. I agree the current solutions for electronic communication are stupid but there is concern about the many vectors and attacker could get all the data.
The fax only ones are the dumbest though because on both sides everyone is just using electronic documents.
The fax only ones are the dumbest though because on both sides everyone is just using electronic documents.
I got a proposal last year from a vendor where I wasn't allowed to copy or download the text. They were one of a handful of proposals I got, so since I wasn't able to share they're stuff with other decision makers they put themselves out of the running. We do take steps ourselves ourselves for communicating sensitive data, but my point is that there can be costs to overusing systems like this.
> in many cases we need to transmit information and also take steps to ensure that the recipient does not forward that data anywhere else without our permission
This is pretty much impossible. It's DRM. It's a pain in the ass for everyone while still not preventing the thing that it is supposed to. The analog hole (https://en.wikipedia.org/wiki/Analog_hole) is always there if nothing else.
Please don't encourage the use of broken software that is fundamentally flawed. I'm not unsympathetic to the goal of controlling the spread of certain information, but when the product plain doesn't work (preventing selecting the message text isn't stopping a cell phone pic for example) and it gets in the way of regular rule-following folks who have to take their time to get around it that's not helping anyone. It's just a total waste of time/money for all involved.
This is pretty much impossible. It's DRM. It's a pain in the ass for everyone while still not preventing the thing that it is supposed to. The analog hole (https://en.wikipedia.org/wiki/Analog_hole) is always there if nothing else.
Please don't encourage the use of broken software that is fundamentally flawed. I'm not unsympathetic to the goal of controlling the spread of certain information, but when the product plain doesn't work (preventing selecting the message text isn't stopping a cell phone pic for example) and it gets in the way of regular rule-following folks who have to take their time to get around it that's not helping anyone. It's just a total waste of time/money for all involved.
yes or like how my kernel driver reverses the polarity of your webcam to emit an infrared laser which makes it nigh impossible to photograph the screen,
which our internal research shows is the typical way of exfiltrating information when right click is disabled by javascript
wear eye protection
which our internal research shows is the typical way of exfiltrating information when right click is disabled by javascript
wear eye protection
To me that is all just unreasonable expectations in the first place. None of the reasons people want that kind of control and knowledge are valid excuses for the overreach. It's just something they want just like the countless things anyone wants.
All across the board MS picks the wrong people to say 'No, tough shit, gtf over yourself." to. They say it to normal users who want to do reasonable things, instead of to business owners and managers who want powers they have no moral right to.
It's fundamentally impossible to control information after it is communicated, no matter what technical gimmicks you concoct, and so it's invalid to even try in the first place. It's barking up the wrong tree and only harming the innocent and not even hindering the criminal.
If something is that precious then keep it in an airgapped lab and frisk people for cell phones at the door, and get nothing much done with that data that's so inconvenient to access.
If you need other people to access the info, then get over yourself and simply have people sign standard legal agreements. If the recipient gets hacked or something then they get hacked. That will still happen regardless. The annoying special access didn't change anything. A hacked client machine can siphon that same data.
MS just doesn't ever say "get over yourself" to the right people. They say it to you & me but treat the most offensive ideas from buisiness owners as very serious and valid needs.
It's made them a lot of money so it's not changing of course. I don't mean to pretend that there is any way or any remotest hope to change that. Only to point out how it's fundamentally wrong, and one of the reasons to simply try to avoid using any of their products and services as much as you can manage.
Goes all the way back to read receipts. The knowledge of when exactly I viewed a correspondence is obviously useful to a sender, but that usefulness does not make it something they have any right to, no matter what the excuse or rationalization is, no matter how much you try to invoke important sounding things that the message might have been about or how important sounding the consequenses like if a court case hinged on proving that you received a message or something. Not only does no one have the right to that knowledge, the mechanism doesn't even prove what it claims to prove anyway. A read receipt still does not prove that I read a message, only that an email client performed the transaction. If you really need an ack for a message, then you have the recipient, the person, send an ack, as in send another message back. Or send the message via a process server. If it's not important enough to justify a process server, then it's just not that critical and you should just get over yourself and accept that the recipient will get to it when they get to it, and you will survive not having this bit of control and visibility into someone else's life.
All across the board MS picks the wrong people to say 'No, tough shit, gtf over yourself." to. They say it to normal users who want to do reasonable things, instead of to business owners and managers who want powers they have no moral right to.
It's fundamentally impossible to control information after it is communicated, no matter what technical gimmicks you concoct, and so it's invalid to even try in the first place. It's barking up the wrong tree and only harming the innocent and not even hindering the criminal.
If something is that precious then keep it in an airgapped lab and frisk people for cell phones at the door, and get nothing much done with that data that's so inconvenient to access.
If you need other people to access the info, then get over yourself and simply have people sign standard legal agreements. If the recipient gets hacked or something then they get hacked. That will still happen regardless. The annoying special access didn't change anything. A hacked client machine can siphon that same data.
MS just doesn't ever say "get over yourself" to the right people. They say it to you & me but treat the most offensive ideas from buisiness owners as very serious and valid needs.
It's made them a lot of money so it's not changing of course. I don't mean to pretend that there is any way or any remotest hope to change that. Only to point out how it's fundamentally wrong, and one of the reasons to simply try to avoid using any of their products and services as much as you can manage.
Goes all the way back to read receipts. The knowledge of when exactly I viewed a correspondence is obviously useful to a sender, but that usefulness does not make it something they have any right to, no matter what the excuse or rationalization is, no matter how much you try to invoke important sounding things that the message might have been about or how important sounding the consequenses like if a court case hinged on proving that you received a message or something. Not only does no one have the right to that knowledge, the mechanism doesn't even prove what it claims to prove anyway. A read receipt still does not prove that I read a message, only that an email client performed the transaction. If you really need an ack for a message, then you have the recipient, the person, send an ack, as in send another message back. Or send the message via a process server. If it's not important enough to justify a process server, then it's just not that critical and you should just get over yourself and accept that the recipient will get to it when they get to it, and you will survive not having this bit of control and visibility into someone else's life.
> I suppose it ensures that if the recipient isn’t using TLS with SMTP then it’s not sent unencrypted over the wire, …
I discovered setting up an old IP camera recently that it’s now very hard to send an unencrypted email via SMTP. Nearly all servers refuse to relay unauthenticated emails (no username and password), and only permit authentication if the connection is SSL or promoted to SSL via STARTTLS (ie encrypted).
(I mention it because the camera wouldn’t cooperate or tell me what the problem was - ended up having to learn Wireshark and read the relevant RFCs re Authenticated SMTP).
I discovered setting up an old IP camera recently that it’s now very hard to send an unencrypted email via SMTP. Nearly all servers refuse to relay unauthenticated emails (no username and password), and only permit authentication if the connection is SSL or promoted to SSL via STARTTLS (ie encrypted).
(I mention it because the camera wouldn’t cooperate or tell me what the problem was - ended up having to learn Wireshark and read the relevant RFCs re Authenticated SMTP).
I went through this process just the other day, setting up Postfix on a Zerotier network. Postfix lets you specify a "mynetworks" config option that lets you allow certain IP ranges. I added the Zerotier IPv6 assigned ranges to this list, disabled any form of TLS on the smtpd end, and was able to effectively turn off TLS. It was more annoying than I thought it would be but it makes sense given how few real world deployments lack TLS these days.
For me, everything has been said here already: https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read, and for those people, encrypted email is LARP security. It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
Totally agree that there is no way of doing email right. If you want security, use other messaging systems, like signal, for all the reasons explained in that post.
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read, and for those people, encrypted email is LARP security. It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
Totally agree that there is no way of doing email right. If you want security, use other messaging systems, like signal, for all the reasons explained in that post.
> It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
Right now my bank, pension fund, utility supplier etc regularly e-mail me to inform me that a new statement is available. But they don't attach the statement to the e-mail... because "it isn't secure"
So there is real-world demand for a properly secured e-mail system. If we could jump in a time machine, go back 50 years and add end-to-end encryption to e-mail, I'd be getting my bank statements by e-mail.
(The chance of my bank deciding to deploy PGP is approximately one in a billion - which is why we'd need a time machine)
Right now my bank, pension fund, utility supplier etc regularly e-mail me to inform me that a new statement is available. But they don't attach the statement to the e-mail... because "it isn't secure"
So there is real-world demand for a properly secured e-mail system. If we could jump in a time machine, go back 50 years and add end-to-end encryption to e-mail, I'd be getting my bank statements by e-mail.
(The chance of my bank deciding to deploy PGP is approximately one in a billion - which is why we'd need a time machine)
> So there is real-world demand for a properly secured e-mail system.
There is real-world demand for a properly secured messaging system (either real-time or asynchronous) that is as ubiquitous, as accessible, and as technologically neutral/decentralized as email.
I think you hit the nail on the head that if we could go back in time and email was encrypted from the start, it would be great, and there is a demand for that. But people keep trying to do that time travel by adding encryption after the fact, and like you I just don't think PGP works for that, I think it's throwing duck tape on top of a technology that is just not designed to handle it.
I'm not saying we should drop all email and move to something like Matrix, I still use email today for a lot of stuff. And I'm definitely not saying everyone should use Signal as a full email replacement (the phone number requirement and centralization problems make it unsuitable). But in the long, long term it would very likely be easier to drop email and move everyone everywhere to Matrix (or something else, it doesn't have to be an instant messenger), than it would be to try and retroactively make email encryption work well.
There is real-world demand for a properly secured messaging system (either real-time or asynchronous) that is as ubiquitous, as accessible, and as technologically neutral/decentralized as email.
I think you hit the nail on the head that if we could go back in time and email was encrypted from the start, it would be great, and there is a demand for that. But people keep trying to do that time travel by adding encryption after the fact, and like you I just don't think PGP works for that, I think it's throwing duck tape on top of a technology that is just not designed to handle it.
I'm not saying we should drop all email and move to something like Matrix, I still use email today for a lot of stuff. And I'm definitely not saying everyone should use Signal as a full email replacement (the phone number requirement and centralization problems make it unsuitable). But in the long, long term it would very likely be easier to drop email and move everyone everywhere to Matrix (or something else, it doesn't have to be an instant messenger), than it would be to try and retroactively make email encryption work well.
What seems to be the problem with pgp (apart from nobody using it)
I think that’s the biggest problem, but there are others.
Off the top of my head:
- PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.
- PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
- PGP doesn’t encrypt metadata.
- PGP doesn’t give forward secrecy.
I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
Transport layer security (and enforcing that) is definitely good for email, and we’ve moved the state of the art beyond where it was in the ‘70s, but I think the quest for true e2ee in SMTP-based email is probably not worth the effort.
Email should be thought of as having certain tradeoffs (like messages living unencrypted on servers, and relying fully on server to server trust), and for things that need e2ee, you should use something like Signal instead.
Off the top of my head:
- PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.
- PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
- PGP doesn’t encrypt metadata.
- PGP doesn’t give forward secrecy.
I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
Transport layer security (and enforcing that) is definitely good for email, and we’ve moved the state of the art beyond where it was in the ‘70s, but I think the quest for true e2ee in SMTP-based email is probably not worth the effort.
Email should be thought of as having certain tradeoffs (like messages living unencrypted on servers, and relying fully on server to server trust), and for things that need e2ee, you should use something like Signal instead.
>- PGP doesn’t give forward secrecy.
Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret key material will be compromised. With an asynchronous, offline capable medium like encrypted email the secret key material can be protected very very well. A message archive accessible to the user for all practical purposes negates the value of forward secrecy. Most people like to keep their old emails around. Most people like to keep any form of messages around so that forward secrecy has little practical value in most forms of E2EE messaging.
There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
More discussion: https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret key material will be compromised. With an asynchronous, offline capable medium like encrypted email the secret key material can be protected very very well. A message archive accessible to the user for all practical purposes negates the value of forward secrecy. Most people like to keep their old emails around. Most people like to keep any form of messages around so that forward secrecy has little practical value in most forms of E2EE messaging.
There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
More discussion: https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
The other person replying already pointed out why this is an apples-to-oranges sort of argument, but for one specific point:
> There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it.
Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm?
The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?
> There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it.
Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm?
The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?
Forward secrecy is just forgetting the secret key material. The trick is the do it in a convenient way. In the case of something offline capable like OpenPGP over email, the inconvenience is in having to redistribute your keys before forgetting the secret key. You don't even have to reestablish any trust, that just works.
I did a demonstration using GnuPG to provide a practical example:
* https://articles.59.ca/doku.php?id=pgpfan:gpgburn
I did a demonstration using GnuPG to provide a practical example:
* https://articles.59.ca/doku.php?id=pgpfan:gpgburn
OMFG. This is the sort of thing that makes people not want to use PGP.
"It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
"It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
Of course no one is actually going to do that. The point is that it is trivially possible. The question is: why do PGP users/developers not bother?
I suspect the answer you're looking for is that it's not necessary, but the much more likely reason is that the UX is horrible and it's error-prone, and even out of the few people who use PGP for this kind of stuff, a fairly sizable chunk of users probably don't even know what forward secrecy is. I would say the expectation that PGP users need to be informed enough about encryption to make a personal decision for themselves when to change their keys is itself a somewhat damning indictment of the PGP ecosystem. You shouldn't have to be an expert in this stuff to have good encryption.
Zooming out a bit, we could ask the same question that you've posed about email more broadly: why do most email users not bother with PGP encryption at all? Why do many client developers decide to not even add support to their apps?
If you take the perspective that lack of mainstream adoption of a security technique is evidence that the security technique has no value, then it's hard not to conclude that SMS and Facebook Messenger are both fine and we're all wasting our time with encrypted messaging of any kind. But my perspective is that people use more secure tools (in part) only once they're at least as accessible and usable as the other tools/platforms that they already have.
----
From your linked article:
> This process is very manual. There are no GnuPG --preburn and --burn commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system.
PGP does not have a generally accessible, vetted way to automatically create those subkeys and distribute them that any non-technical (or even reasonably technical) user can take advantage of: if it did then the blogpost wouldn't exist. So of course people don't do that stuff, it's not surprising that people don't manually edit keys. The problem is when developers and proponents then respond to that by saying, "we don't need a generally accessible, vetted way to automatically create and distribute subkeys because people don't do that." Then the whole conversation starts getting really circular.
People use forward secrecy in Signal because it's on by default and works even if they don't know what forward secrecy is. Of course sometimes we can look at an ecosystem and we can take cues about user needs based on what they currently use. However, you have to be very careful about that. Don't fall into the same trap that (just as one example) Mozilla falls into, where they'll move an option into a buried preference menu and then say, "no one is clicking this anymore, guess we should remove it from the browser entirely." Sometimes users don't use features purely because they're not convenient, or accessible, or because they don't know the features exist.
It's also worth noting that broadly, most E2EE messaging platforms are moving towards forward secrecy, and PGP encrypted email is somewhat of an outcast in saying that forward secrecy doesn't matter. So it's not really like forward secrecy is easy everywhere and people go and turn it off because they don't need it. Increasingly, it's just older systems like PGP where people have decided not to approach messaging this way. I would posit the reason for that split is because PGP has bad UX for forward secrecy and most people using it or building around it know that doing unconventional things in PGP is a recipe for accidentally shooting yourself in the foot.
Zooming out a bit, we could ask the same question that you've posed about email more broadly: why do most email users not bother with PGP encryption at all? Why do many client developers decide to not even add support to their apps?
If you take the perspective that lack of mainstream adoption of a security technique is evidence that the security technique has no value, then it's hard not to conclude that SMS and Facebook Messenger are both fine and we're all wasting our time with encrypted messaging of any kind. But my perspective is that people use more secure tools (in part) only once they're at least as accessible and usable as the other tools/platforms that they already have.
----
From your linked article:
> This process is very manual. There are no GnuPG --preburn and --burn commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system.
PGP does not have a generally accessible, vetted way to automatically create those subkeys and distribute them that any non-technical (or even reasonably technical) user can take advantage of: if it did then the blogpost wouldn't exist. So of course people don't do that stuff, it's not surprising that people don't manually edit keys. The problem is when developers and proponents then respond to that by saying, "we don't need a generally accessible, vetted way to automatically create and distribute subkeys because people don't do that." Then the whole conversation starts getting really circular.
People use forward secrecy in Signal because it's on by default and works even if they don't know what forward secrecy is. Of course sometimes we can look at an ecosystem and we can take cues about user needs based on what they currently use. However, you have to be very careful about that. Don't fall into the same trap that (just as one example) Mozilla falls into, where they'll move an option into a buried preference menu and then say, "no one is clicking this anymore, guess we should remove it from the browser entirely." Sometimes users don't use features purely because they're not convenient, or accessible, or because they don't know the features exist.
It's also worth noting that broadly, most E2EE messaging platforms are moving towards forward secrecy, and PGP encrypted email is somewhat of an outcast in saying that forward secrecy doesn't matter. So it's not really like forward secrecy is easy everywhere and people go and turn it off because they don't need it. Increasingly, it's just older systems like PGP where people have decided not to approach messaging this way. I would posit the reason for that split is because PGP has bad UX for forward secrecy and most people using it or building around it know that doing unconventional things in PGP is a recipe for accidentally shooting yourself in the foot.
> This sort of attack could not reveal any messages archived off the network due to Signal's forward secrecy. Let's compare the end result to an encrypted email client running on the same phone using traditional passphrase protection [...] So the encrypted email actually ends up providing a better result for the user. That is because it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
I have some issues:
First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated.
Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device.
Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients.
Just to make this point more clearly:
> it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption.
----
> Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.
I have some issues:
First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated.
Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device.
Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients.
Just to make this point more clearly:
> it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption.
----
> Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.
>First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form,...
No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
>...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous.
I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
>...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous.
I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
> Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that.
You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that.
> They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to.
They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever.
----
There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.
That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that.
You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that.
> They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to.
They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever.
----
There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.
> PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929?
In the case up above in this thread branch of the poster's bank not emailing statements because it is not secure, key discovery would be easy. The bank would have a form available only when logged in to their online banking site to enable statements by email with a way to upload your public key.
My guess is that for most people who could benefit from emailing encrypted documents it is similar. They have a good secure channel to give the other party their public key.
I'd rather that something better than PGP be used though.
In the case up above in this thread branch of the poster's bank not emailing statements because it is not secure, key discovery would be easy. The bank would have a form available only when logged in to their online banking site to enable statements by email with a way to upload your public key.
My guess is that for most people who could benefit from emailing encrypted documents it is similar. They have a good secure channel to give the other party their public key.
I'd rather that something better than PGP be used though.
Yeah, I think that’s fair.
As a nerd, it does seem to me like I should be able to give the bank a public key and let me worry about my own security. But I don’t think this is actually what the bank or the user wants—they don’t want encryption per se, they want authentication, and an HTTPS link in an email (that you have to login to view) achieves that.
As a nerd, it does seem to me like I should be able to give the bank a public key and let me worry about my own security. But I don’t think this is actually what the bank or the user wants—they don’t want encryption per se, they want authentication, and an HTTPS link in an email (that you have to login to view) achieves that.
> PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.
That is what WKD is for and is already implemented by multiple providers.
> PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
> PGP doesn’t encrypt metadata.
What metadata are you concerned about here? Subject lines? GPG is quite versatile so I'm not sure what metadata you are worried about.
> PGP doesn’t give forward secrecy.
Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
> I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them.
That is what WKD is for and is already implemented by multiple providers.
> PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
> PGP doesn’t encrypt metadata.
What metadata are you concerned about here? Subject lines? GPG is quite versatile so I'm not sure what metadata you are worried about.
> PGP doesn’t give forward secrecy.
Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
> I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them.
> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
Surely it’s on me, if I wanted the content to be secret?
> What metadata are you concerned about here? Subject lines?
I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
> Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
> I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them
I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
Surely it’s on me, if I wanted the content to be secret?
> What metadata are you concerned about here? Subject lines?
I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
> Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
> I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them
I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
No matter what encryption you use, if your recipient gets compromised there is nothing you can do except don't sign the message with a published public key and send the message anonymously. Then, at least, it would be more difficult to trace back to you unless you include personally identifiable information in the encrypted message.
> I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
First, when it comes to traffic patterns I have no clue what that means. You can hide the recipient with GPG, so they have some plausible deniability as long as someone else doesn't have their secret key and passphrase.
You can encrypt the subject line pending email client support to decrypt, but really it seems pointless. Might as well just say `hello` or `secure` in the subject line. I imagine you could also create an RFC to add an encrypted subject to the header if one doesn't exist already.
> As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
It doesn't have to be a lot of hassle. If I remember correctly, Keybase may have had something similar for messaging. It just hasn't been done because instead of using GPG, a lot of people want to implement something else, which is fine as long as it is secure. GPG is secure though which is why people throughout the intelligence community use it frequently and journalists that want security.
Maybe for PFS something like age makes more sense, but GPG has been around and is more tried and tested.
> think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
GPG is usable and usably secure, if you know even some of the basics of what you're doing. Really, just looking through the docs on GPG's website provides a vast resource of information. It can be overwhelming for grandma, and yes sometimes the docs are confusing in certain areas, but it is not challenging for people in tech that have a little patience (doesn't require a lot).
There certainly isn't anything stopping GPG from being the default except competing solutions. It has been pretty much the default for email security for some time.
No matter what encryption you use, if your recipient gets compromised there is nothing you can do except don't sign the message with a published public key and send the message anonymously. Then, at least, it would be more difficult to trace back to you unless you include personally identifiable information in the encrypted message.
> I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
First, when it comes to traffic patterns I have no clue what that means. You can hide the recipient with GPG, so they have some plausible deniability as long as someone else doesn't have their secret key and passphrase.
You can encrypt the subject line pending email client support to decrypt, but really it seems pointless. Might as well just say `hello` or `secure` in the subject line. I imagine you could also create an RFC to add an encrypted subject to the header if one doesn't exist already.
> As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
It doesn't have to be a lot of hassle. If I remember correctly, Keybase may have had something similar for messaging. It just hasn't been done because instead of using GPG, a lot of people want to implement something else, which is fine as long as it is secure. GPG is secure though which is why people throughout the intelligence community use it frequently and journalists that want security.
Maybe for PFS something like age makes more sense, but GPG has been around and is more tried and tested.
> think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
GPG is usable and usably secure, if you know even some of the basics of what you're doing. Really, just looking through the docs on GPG's website provides a vast resource of information. It can be overwhelming for grandma, and yes sometimes the docs are confusing in certain areas, but it is not challenging for people in tech that have a little patience (doesn't require a lot).
There certainly isn't anything stopping GPG from being the default except competing solutions. It has been pretty much the default for email security for some time.
It feels like you’re arguing that, technically, GPG _can_ be used to achieve the same level of security as modern messaging platforms. That’s probably true. (I say “probably” because I’m not a cryptographer, so I’m not qualified to speak to the cipher algorithms used.)
My claim was never that, though. My claim is that in the “normal” usage of PGP, it’s substantially less secure than modern alternatives, and that this is a mostly inherent byproduct of the use cases for which PGP appears to be constructed.
Succinctly: it’s hard to use PGP securely.
Can you do it? Probably. Could PGP be the default if everyone gave up on the easier to use, more secure alternatives? Well, on this point I am skeptical: before Signal, Wire, Threema, WhatsApp, etc—some of us remember those days!—the “default” was plaintext email. Not PGP.
PGP had 30 years to become the norm. During the first twenty or so, it had no real competitors other than S/MIME. And, here we are.
There are a lot of areas—fountain pens, for example, or vintage sports cars—where old technology has its own appeal, but encrypted communications isn’t one of them.
My claim was never that, though. My claim is that in the “normal” usage of PGP, it’s substantially less secure than modern alternatives, and that this is a mostly inherent byproduct of the use cases for which PGP appears to be constructed.
Succinctly: it’s hard to use PGP securely.
Can you do it? Probably. Could PGP be the default if everyone gave up on the easier to use, more secure alternatives? Well, on this point I am skeptical: before Signal, Wire, Threema, WhatsApp, etc—some of us remember those days!—the “default” was plaintext email. Not PGP.
PGP had 30 years to become the norm. During the first twenty or so, it had no real competitors other than S/MIME. And, here we are.
There are a lot of areas—fountain pens, for example, or vintage sports cars—where old technology has its own appeal, but encrypted communications isn’t one of them.
The subject line is message text! It's message! That's literally what it is! It's baffling (and revealing) to see email encryption advocates downplay the fact that subjects are exposed in plaintext. The retcon here is that subjects are somehow intended as the unencrypted, public part of the message, as if that was a normal feature of a sealed letter. Go find the last letter you mailed someone (or try to remember; I know it's been awhile) and look on the envelope for the part where you wrote what the message was about.
I explained ways to avoid this. Write `secure` for the subject and include the actual subject in the encrypted message. Propose an RFC to include an encrypted subject in the headers. Encrypted the subject line. I don't think this is valid considering that there are solutions.
When you're at the point of making excuses for important parts of the message text being revealed in plaintext, the useful debate about email encryption is basically over.
That is how email works. The subject isn't an important part of message text, the message is.
What if instead of writing “secure” in the subject, I just don’t send the email and instead use Signal or WhatsApp where all the text is encrypted end to end?
It’s not clear why it’s desirable to keep bolting things onto email in an attempt to somehow make it eventually match the security profile that we can already get by just using other existing options.
It’s not clear why it’s desirable to keep bolting things onto email in an attempt to somehow make it eventually match the security profile that we can already get by just using other existing options.
In any sufficiently long discussion of PGP’s merits, it becomes obvious that those arguing for PGP are not motivated by a desire to keep communications confidential, but, rather, to justify use of PGP.
So, why not just use Signal or WhatsApp?
‘Cause they’re not PGP.
So, why not just use Signal or WhatsApp?
‘Cause they’re not PGP.
Not going to rehash what other people are writing about PGP, that could be a much longer conversation. But it's not just PGP that's the problem, PGP just happens to be what people are using to encrypt email.
If it was just PGP that was the problem, we'd use something else to encrypt our emails and it would be fine. But the problem is that any system that works like PGP where we're primarily encrypting message contents, where we're not thinking about stuff like forward secrecy -- that's not good for email. Email itself isn't good for that because email doesn't really lend itself to E2EE, regardless of what you use to do the encrypting and key validation.
So you could have a version of PGP that was amazing and brilliant, and it still wouldn't really be a good fit for encrypting email, because email is not a good fit for encrypting email. The entire structure of how email works makes it difficult to do encryption in a user-friendly, accessible way.
I am also pretty skeptical of PGP (see some of the other comments), but that's not specifically why I mentioned it in my original comment. I only brought it up because most email encryption schemes I see are using PGP, and I don't think that PGP miraculously solves the problem. It's not good enough to paper over the fundamental flaws in email itself.
If it was just PGP that was the problem, we'd use something else to encrypt our emails and it would be fine. But the problem is that any system that works like PGP where we're primarily encrypting message contents, where we're not thinking about stuff like forward secrecy -- that's not good for email. Email itself isn't good for that because email doesn't really lend itself to E2EE, regardless of what you use to do the encrypting and key validation.
So you could have a version of PGP that was amazing and brilliant, and it still wouldn't really be a good fit for encrypting email, because email is not a good fit for encrypting email. The entire structure of how email works makes it difficult to do encryption in a user-friendly, accessible way.
I am also pretty skeptical of PGP (see some of the other comments), but that's not specifically why I mentioned it in my original comment. I only brought it up because most email encryption schemes I see are using PGP, and I don't think that PGP miraculously solves the problem. It's not good enough to paper over the fundamental flaws in email itself.
I have a canned response to this hoary old chestnut:
* https://articles.59.ca/doku.php?id=pgpfan:tpp
* https://articles.59.ca/doku.php?id=pgpfan:tpp
You also have a lot of weird cryptographic beliefs, like "authenticated encryption is a misfeature for tools like PGP, because unauthenticated ciphertext helps with data recovery", or "GPGME definitely doesn't just execute the GPG binary in order to perform PGP operations", or "forward secrecy is overrated because people keep all their old messages around" (also: "people should keep all their old messages around"). People that also believe these weird things will find your canned reply convincing. Cryptography engineers generally will not.
The word "hoary" means "grey-haired". "Stop Using Encrypted Email" was published in 2020; even in dog years, it's not "hoary".
The word "hoary" means "grey-haired". "Stop Using Encrypted Email" was published in 2020; even in dog years, it's not "hoary".
I think most people complaining about GPG just don't want to be bothered with figuring anything out. They'd rather input their phone number into some cloud app that says it is secure and feel more secure than actually be bothered with understanding security in the first place.
This is pretty wild.
I’ve spent a decade working in the industry, most of it unwinding complex infrastructure and codebases. I don’t hate GPG because I can’t be bothered to figure it out. I understand it and it’s bad at handling the problems it claims to solve.
I’ve spent a decade working in the industry, most of it unwinding complex infrastructure and codebases. I don’t hate GPG because I can’t be bothered to figure it out. I understand it and it’s bad at handling the problems it claims to solve.
Such as? Can you provide any examples?
I really don't have time to go through every item in the biased article, but you can hide recipients, you can use Ed25519. Seriously, if I was influenced by every blog post I read then I would probably be using Windows 7 still and trusting everything Gartner says.
It seems a bit rude to ask me for examples, have me provide one, and then just shrug it off that you don’t have time to address the items.
“You can use ed25519” kindof flies in the face of the point being made in the post, which is that sure, you can use modern crypto, but you’re bounded by the lowest common denominator, and GPG’s lowest common denominator is horrible broken crypto selections.
“You can use ed25519” kindof flies in the face of the point being made in the post, which is that sure, you can use modern crypto, but you’re bounded by the lowest common denominator, and GPG’s lowest common denominator is horrible broken crypto selections.
Yes... I agree that can work....
But look at it from the banks perspective. If they email you and ask for you to log in the bank can see who you are, and capture any info in case of fraud.
If they sent it as a secure message, they cannot capture any info on who saw it... They just know it was sent.
But look at it from the banks perspective. If they email you and ask for you to log in the bank can see who you are, and capture any info in case of fraud.
If they sent it as a secure message, they cannot capture any info on who saw it... They just know it was sent.
Does your bank at least use STARTTLS? I know banks that don't.
https://try.popho.be/email.html#tests
https://try.popho.be/email.html#tests
"Stop Using Encrypted Email" is mostly a weak restatement of "The PGP Problem". That anti-PGP rant has issues[1] that are relevant here.
The new bit is the idea that someone will leak an email with an unencrypted CC: or forward. That's an easy to resolve user factors issue. If we were actually encrypting our emails then attempts to send unencrypted emails could easily be highlighted and discouraged.
Long form asynchronous messaging is important and useful, particularly in business. You can't just wave it away. By nature it can be made much more secure than something like an instant messenger[2]. The Cellebrite attack against Signal is a good example of that. Cellebrite gets all the archived messages in the case of Signal and none of the PGP messages.
[1] https://articles.59.ca/doku.php?id=pgpfan:tpp
[2] https://articles.59.ca/doku.php?id=em:emailvsim
The new bit is the idea that someone will leak an email with an unencrypted CC: or forward. That's an easy to resolve user factors issue. If we were actually encrypting our emails then attempts to send unencrypted emails could easily be highlighted and discouraged.
Long form asynchronous messaging is important and useful, particularly in business. You can't just wave it away. By nature it can be made much more secure than something like an instant messenger[2]. The Cellebrite attack against Signal is a good example of that. Cellebrite gets all the archived messages in the case of Signal and none of the PGP messages.
[1] https://articles.59.ca/doku.php?id=pgpfan:tpp
[2] https://articles.59.ca/doku.php?id=em:emailvsim
Long-form asynchronous messaging is important and useful. It's just that SMTP email makes it virtually impossible to do so securely. As the author of both documents you cited, I take issue with the idea that one is a restatement of the other; that's obviously not true. The concerns in "S.U.E.A." are endemic to all forms of encrypted SMTP email, and the concerns in "T.P.P." are endemic to most possible uses of PGP. They're related sets of problems, but not even close to perfectly intersecting sets; the MasterCard logo, not the Toyota logo as you'd have it.
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read
Do you have glasses? - Could've gotten you killed under a different regime in a different time.
Do you own foreign books? - Could've gotten you killed under a different regime in a different time.
Do you have a mental disorder? - Could've gotten you killed under a different regime in a different time.
Is your religion not the majority in your country? - ...
Now consider the fact that regimes change. How uninteresting are your emails?
Do you have glasses? - Could've gotten you killed under a different regime in a different time.
Do you own foreign books? - Could've gotten you killed under a different regime in a different time.
Do you have a mental disorder? - Could've gotten you killed under a different regime in a different time.
Is your religion not the majority in your country? - ...
Now consider the fact that regimes change. How uninteresting are your emails?
And that is exactly the point made in that article. If what you put in that email can get you killed, then don't put it in an email, even encrypted.
There are just too many ways things can go wrong, and of course they will go wrong at some point.
If you need confidentiality you need, at the minimum, disappearing messages, and for that to be the case all the way, you can't rely on decentralisation systems with various implementations.
Sorry for interoperable decentralised lovers, that includes myself, but you need control over the whole chain. And email is just the opposite of this.
There are just too many ways things can go wrong, and of course they will go wrong at some point.
If you need confidentiality you need, at the minimum, disappearing messages, and for that to be the case all the way, you can't rely on decentralisation systems with various implementations.
Sorry for interoperable decentralised lovers, that includes myself, but you need control over the whole chain. And email is just the opposite of this.
> Do you have glasses? - Could've gotten you killed under a different regime in a different time.
Really, where then?
Suppose today it's opposite: Eye Sight will detoriate when not wearing proscription glasses, which gives actual minus points on sight and maybe three pedestrian red lights worth in negative social credit.
Really, where then?
Suppose today it's opposite: Eye Sight will detoriate when not wearing proscription glasses, which gives actual minus points on sight and maybe three pedestrian red lights worth in negative social credit.
During the Cambodia genocide[1]:
"... people who were stereotypically thought of as having intellectual qualities, such as wearing glasses or speaking multiple languages, were executed out of fear that they would rebel against the Khmer Rouge."
[1] https://en.wikipedia.org/wiki/Cambodian_genocide
"... people who were stereotypically thought of as having intellectual qualities, such as wearing glasses or speaking multiple languages, were executed out of fear that they would rebel against the Khmer Rouge."
[1] https://en.wikipedia.org/wiki/Cambodian_genocide
>> Ordinary people don’t exchange email messages that any powerful adversary would bother to read
Wait, what? Adversaries do read emails of ordinary/average people. From Google[0] to the NSA[1]. Are we just pretending this doesn't happen?
[0] https://web.archive.org/web/20190331015638/https://www.wsj.c...
[1] https://www.theverge.com/2017/4/28/15474828/nsa-surveillance...
Wait, what? Adversaries do read emails of ordinary/average people. From Google[0] to the NSA[1]. Are we just pretending this doesn't happen?
[0] https://web.archive.org/web/20190331015638/https://www.wsj.c...
[1] https://www.theverge.com/2017/4/28/15474828/nsa-surveillance...
Except there are many other emails people don't want to be read by the wrong party. A powerful adversary or nation-state is not the only adversary.
> If you want security, use other messaging systems, like signal,
signal is not decentralized and requires phone numbers tied to your real identity. no thanks.
signal is not decentralized and requires phone numbers tied to your real identity. no thanks.
Try Session [0]. Decentralized, no phone numbers and adding contacts is done by either sharing your ID or an QR-code. It works well but, at this time, only texting. Does have pretty apps for iOS/Android and most desktops OS's
[0]https://getsession.org/
EDIT grammar
[0]https://getsession.org/
EDIT grammar
The problem with that link is pretty clear:
(1) SMIME/x509, and national security variants are incredibly popular for intra-organizational secure email (2) Secure Webmails have came on the scene in a big way.
Where SMIME/x509 fails, web-of-trust based solutions succeeds, and vice versa.
Working across both areas means we need solutions to bridge between the two worlds, and to buttress each other respective weaknesses in the trust model.
(1) SMIME/x509, and national security variants are incredibly popular for intra-organizational secure email (2) Secure Webmails have came on the scene in a big way.
Where SMIME/x509 fails, web-of-trust based solutions succeeds, and vice versa.
Working across both areas means we need solutions to bridge between the two worlds, and to buttress each other respective weaknesses in the trust model.
There is a very good point about the difficult-to-impossibility of securing email.
BUT:
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read,
This just one hundred percent incorrect and it completely misstates the problem.
The problem is not that Alice and Bob are the focus of intensely focused surveillance, in the sense that they are up against a powerful adversary themselves.
The problem is that Alice and Bob live in a society where those who can and want to make such decisions, are implementing drag-net surveillance at every possible corner of society that they can get away with.
There is a powerful adversary and it would very much like to to read any and all of our communication.
In almost all cases this is consequence-free for Alice and Bob - but this is not Freedom.
My communication is mine it's not there for google so scan for ways to sell me useless shit, and it's not there for Big Brother for training their precog-ML models on it.
The threat model is not "The CIA wants to rubberhose me into revealing information" it's "The NSA routinely opens all of my letters, just to make sure I am not a terrorist/commie/vagrant/etc".
BUT:
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read,
This just one hundred percent incorrect and it completely misstates the problem.
The problem is not that Alice and Bob are the focus of intensely focused surveillance, in the sense that they are up against a powerful adversary themselves.
The problem is that Alice and Bob live in a society where those who can and want to make such decisions, are implementing drag-net surveillance at every possible corner of society that they can get away with.
There is a powerful adversary and it would very much like to to read any and all of our communication.
In almost all cases this is consequence-free for Alice and Bob - but this is not Freedom.
My communication is mine it's not there for google so scan for ways to sell me useless shit, and it's not there for Big Brother for training their precog-ML models on it.
The threat model is not "The CIA wants to rubberhose me into revealing information" it's "The NSA routinely opens all of my letters, just to make sure I am not a terrorist/commie/vagrant/etc".
I can also screenshot my device showing signal/whatsapp, that doesn't make them insecure.
There is a lot of email based verification/authentication happening which would benefit if the email encryption was more widely accepted.
There is a lot of email based verification/authentication happening which would benefit if the email encryption was more widely accepted.
There are plenty of ways of doing email right, but we've lost what we had in the early days, the ability to form concensus, and enact change, via RFCs.
Mostly because the big boys want control.
Mostly because the big boys want control.
> Mostly because the big boys want control.
I'd rather say the issue is that the big boys' business is NOT mails, so their goal is to provide the minimum viable mail service, and not spend one dollar more on it.
While once upon a time, when companies were actually providing email service, they had to innovate to keep on top.
I'd rather say the issue is that the big boys' business is NOT mails, so their goal is to provide the minimum viable mail service, and not spend one dollar more on it.
While once upon a time, when companies were actually providing email service, they had to innovate to keep on top.
> I'd rather say the issue is that the big boys' business is NOT mails, so their goal is to provide the minimum viable mail service, and not spend one dollar more on it.
Plenty of money was spent criminalising crypto by the big boys.
Even disregarding that fact, your equation makes no sense because AOL or whatever big BS you have in mind has null interest providing a product they have to spend money on with zero realistic ROI.
Since arpa net arose eventually from the same party poopers, nothing of this should come as a real surprise.
Plenty of money was spent criminalising crypto by the big boys.
Even disregarding that fact, your equation makes no sense because AOL or whatever big BS you have in mind has null interest providing a product they have to spend money on with zero realistic ROI.
Since arpa net arose eventually from the same party poopers, nothing of this should come as a real surprise.
Mail providers never wrote rfcs. Nor are they expensive, just concensus requiring.
If email was encrypted at rest, gmail would disappear overnight. Gmail's whole purpose is end user data gathering, for profit.
Many other mail providers are the same.
If email was encrypted at rest, gmail would disappear overnight. Gmail's whole purpose is end user data gathering, for profit.
Many other mail providers are the same.
I'd absolutely love an email 2.0 with E2E encryption, but I doubt the ability of the industry/community to create something like that anymore as much as it depresses me. That email is so standard and federated despite pressure to the contrary is something of an accident of history and the time it was developed. The trend now is the opposite. It would probably also require a foundation of secured DNS which could then act as a transparent root of trust, but that hasn't been doing well either. Even a lot of "security experts" insist on stupid shit like Signal or the like being a replacement. So we'll continue to use email for highly sensitive and secure material and it'll just continue to be a window for a lot of adversaries I guess :(. It's not hard to envision a system with a few simple upgrades to make it both vastly more secure and help deal with spam at a much more root level, the pieces exist at the technology level. Yet I doubt it'll get out together and adopted. Path dependency is hard.
There's a handful of email hosting companies that have huge market share. If Microsoft and Google worked together they could implement any new email standard they want and everyone would have to follow.
Exactly. If Microsoft or Google or both wanted to create a standard for Guaranteed Delivery and pile all sorts of stuff on it, they could.
If they did it right, it might even be a good thing. But there's not really much desire/push for it, because spam got "mostly solved" well enough.
You'd want it to be a feature-add (if enabled and used, your bank can send you secure statements direct to your email box that nobody else can read, etc) so you actually gain something; but then you have the whole "Google and Microsoft have MITM themselves on almost all email" problem anyway.
If they did it right, it might even be a good thing. But there's not really much desire/push for it, because spam got "mostly solved" well enough.
You'd want it to be a feature-add (if enabled and used, your bank can send you secure statements direct to your email box that nobody else can read, etc) so you actually gain something; but then you have the whole "Google and Microsoft have MITM themselves on almost all email" problem anyway.
>>spam got "mostly solved" well enough.
Did it though? Gmail is still having a tough time blocking all spam.
Did it though? Gmail is still having a tough time blocking all spam.
And most people with independently-run mail servers are screwed because it's "potential spam". Now you have almost no choice but to use a big tech platform if you want your email to be of any use. Which is ridiculous, and completely antithetical to a federated platform
What's wrong with Signal? It works, it moves files, I don't have to jump through filtering hoops to do so. Signal is an excellent replacement for email when you need security.
Signal is another walled garden actively trying to prevent decentralization. Expect that it will fail at some point in the future either due to too many users and too few money or something else.
Consider Matrix instead.
Consider Matrix instead.
* History can't be synced into newly logged in devices
* Requires phone number
* How do I run my own server?
* Doesn't have good spam protection
* Individual messages can't be categorised into folders and/or archived, then searched by category
* Requires phone number
* How do I run my own server?
* Doesn't have good spam protection
* Individual messages can't be categorised into folders and/or archived, then searched by category
Agree with sibling comments, but Signal is very much ‘good enough’ for a lot of people and use cases. I was able to covert my family to Signal, including grandparents, but I could not have done that with Matrix, Wire, PGP, etc. It’s the entry point for decent encrypted chat.
This. And because it uses phone numbers, more people I know are less reluctant to switch to it.
Use Session. It's just as easy, and more secure + decentralized. So it's better in just about every way.
Gotta love that someone always mentions Signal when it's obviously not a replacement for email.
Historical search is de facto absent on desktop since the messages get wiped regularly.
S/MIME could work well but the CA Cert situation doesn't allow it for normal people.
This is a non-starter because it doesn't, and can't, work the way you expect it to.
Email can be thought of as an encrypted communications protocol where the parties can negotiate down to plain text. In other words, it isn't encrypted communication, it's bare communication over which the user might choose to send encrypted information.
Something with the ergonomics of email, but built over a platform with enforceable E2E such as Matrix, would be quite welcome. But it can't be an extension of mail protocols, or reuse the email address space, so it won't be email.
Email can be thought of as an encrypted communications protocol where the parties can negotiate down to plain text. In other words, it isn't encrypted communication, it's bare communication over which the user might choose to send encrypted information.
Something with the ergonomics of email, but built over a platform with enforceable E2E such as Matrix, would be quite welcome. But it can't be an extension of mail protocols, or reuse the email address space, so it won't be email.
No we should not. Logging in from anywhere and seeing all mail without problems, server side search improves the usability immensely. People who need encryption for sensitive stuff should have this capability, but forcing mandatory encryption for everyone like various do-gooders do want to will lead to far too many problems for regular users.
Is this post some kind of a joke? First it complains that most users are unaware that emails even can be encrypted, and then goes off on a tangent about some command line garbage that 0% of these users will be able to use.
Just an FYI for HN, you can add your PGP fingerprint to your profile (along with the keyserver(s) they're on) so that at least HN users who want to communicate with you can use E2E encryption.
And it'll be harder for your email address to be harvested by bots since they'd have to actually download the key to see what address it's for.
And it'll be harder for your email address to be harvested by bots since they'd have to actually download the key to see what address it's for.
It would be a start, and a decent one, for TLS to be required for all my email transmission. It seems like the providers can do the same thing that Chrome did, and put scary security warnings for emails that can't meet encrypted in transmission.
Encryption at rest is another problem, one that I'm not even sure most users want.
Encryption at rest is another problem, one that I'm not even sure most users want.
Agreed that TLS between servers should be promoted and enforced more. In practice, something like 90%+ of email is so encrypted now[1]. Things could be better, but they are not bad.
With encrypted email, encryption at rest and encryption in flight are the same process. It uses an encrypt once scheme[2] which simplifies things immensely. As a result you only have one level of security to worry about.
[1] https://articles.59.ca/doku.php?id=pgpfan:starttls
[2] https://articles.59.ca/doku.php?id=pgpfan:encryptonce
With encrypted email, encryption at rest and encryption in flight are the same process. It uses an encrypt once scheme[2] which simplifies things immensely. As a result you only have one level of security to worry about.
[1] https://articles.59.ca/doku.php?id=pgpfan:starttls
[2] https://articles.59.ca/doku.php?id=pgpfan:encryptonce
TLS would be good start. It is insane that not using it would be allowed anymore.
At rest also a decent idea. Even if provider have the keys.
End-to-End however in system where you need to be able to send message to anyone and expect it to work is rather big can of worms.
At rest also a decent idea. Even if provider have the keys.
End-to-End however in system where you need to be able to send message to anyone and expect it to work is rather big can of worms.
> Therefore, in 2022 a daily email traffic of 333.2 billion emails is expected
I mean, sure, but let's be honest, a big majority of that is going to be spam, the next step down from that are silly little things like email verifications, password resets, notifications, newsletter spam, and other similar crap. As a millennial who doesn't touch emails for work or for personal reasons (because there is Slack, Signal or some other alternative to those two), I could very well be out of touch, but I'd be surprised if actual legitimate emails (both business and consumer) are more than 5% of that number.
I suppose 5% is still a big number, putting it at a comfortable ~16 billion emails.
Anyway, yes, we should be using encryption by default wherever possible, but honestly, encryption isn't easy for the common folk, which is going to be the majority of those 333 billion. Heck, I migrated away from PM and I struggled with a lot of it. As someone who mostly lives in the CLI, GnuPG is not easy to use. Something like MailVelope makes it easier, but still not that easy.
Then there is the matter of administration. Your sysadmin, especially of the bigger orgs, do not want encryption on your emails. Especially when the business you're in is regulated. Imagine being able to casually leak something without anyone knowing what's in the content? I know regulation is usually not a good answer for why not, but within a business, yes, it totally is. As a customer of Big Bank Corp, I do not want employees to be able to mess with my data, money, or worse, the money of the bank so that it can fail and for my money (or the tax payer's in case of govt protections) to be gone because everyone's emails were encrypted.
The only viable solution here is something like ProtonMail, which actually makes it easier to use, at $/£/€ 5 per month, not many are able to afford to part with that. And no, their free tier is really not that great. But regardless, even PM doesn't really help if a non PM user sends you an email.
I mean, sure, but let's be honest, a big majority of that is going to be spam, the next step down from that are silly little things like email verifications, password resets, notifications, newsletter spam, and other similar crap. As a millennial who doesn't touch emails for work or for personal reasons (because there is Slack, Signal or some other alternative to those two), I could very well be out of touch, but I'd be surprised if actual legitimate emails (both business and consumer) are more than 5% of that number.
I suppose 5% is still a big number, putting it at a comfortable ~16 billion emails.
Anyway, yes, we should be using encryption by default wherever possible, but honestly, encryption isn't easy for the common folk, which is going to be the majority of those 333 billion. Heck, I migrated away from PM and I struggled with a lot of it. As someone who mostly lives in the CLI, GnuPG is not easy to use. Something like MailVelope makes it easier, but still not that easy.
Then there is the matter of administration. Your sysadmin, especially of the bigger orgs, do not want encryption on your emails. Especially when the business you're in is regulated. Imagine being able to casually leak something without anyone knowing what's in the content? I know regulation is usually not a good answer for why not, but within a business, yes, it totally is. As a customer of Big Bank Corp, I do not want employees to be able to mess with my data, money, or worse, the money of the bank so that it can fail and for my money (or the tax payer's in case of govt protections) to be gone because everyone's emails were encrypted.
The only viable solution here is something like ProtonMail, which actually makes it easier to use, at $/£/€ 5 per month, not many are able to afford to part with that. And no, their free tier is really not that great. But regardless, even PM doesn't really help if a non PM user sends you an email.
> their free tier is really not that great.
Why do you think that their free tier is not great? AFAIK, it works like any other free tier email service but with encryption. Though it does have a limited storage space (which has increased recently). Anyone who would need more than that & has chosen to use PM probably also understands the cost of free products available & will be willing to get paid service
Disclaimer - I am a paid PM user (converted from free tier after using it for few years)
Why do you think that their free tier is not great? AFAIK, it works like any other free tier email service but with encryption. Though it does have a limited storage space (which has increased recently). Anyone who would need more than that & has chosen to use PM probably also understands the cost of free products available & will be willing to get paid service
Disclaimer - I am a paid PM user (converted from free tier after using it for few years)
Organizations may use ADK (additional decryption key) when they want to access what users are emailing to each other (for compliance/security reasons). It can be done with vendor provided software or manually. Here is a short description of how it works:
https://www.go350.com/posts/age-file-encryption/#additional-...
https://www.go350.com/posts/age-file-encryption/#additional-...
The only people who send me messages on email are recruiters. I'd honestly prefer if they'd just discord me so we could have synchronous communication instead of having to wait 24+ hours for a response.
Delta is also viable. I use it for IM and it is TOFU based PGP encryption. It works OK for general email too, though that's not the focus.
See: https://delta.chat/en/
See: https://delta.chat/en/
> Your sysadmin, especially of the bigger orgs, do not want encryption
on your emails.
This is the nub of it. People don't know what they want from technology. Or rather, they are conflicted. Our collective illusion that rational technical concerns drive technology hides the reality that all digital technology is a set of power relations that help or hinder different spheres of interest - often within the same group or individuals. Many people want to do bad things and we have even created laws that insist people do bad things (as piss poor solutionism to the original bad things). Hole, spade, keep digging.
The problem of email can be seen two ways:
1. Bad protocols.
2. Bad actors.
Naturally, as techies we attack (1). Just encrypt it all. Zero trust. Train everybody to use encryption. Enforce it. Let's call that the "Rule of Tech".
By contrast, let's call (2) the "Rule of Law". There are already more than enough laws that deal with the fundamental immorality of reading someone else's private correspondence. However we have carved out so many exceptions, including those in the interests of our own profits, that we now just assume (2) is an intractable feature of the world. It isn't.
Email has shown us time and time again that the solutionism of getting people to use encryption is nigh-on impossible. Even the US government have pretty much said PGP is a dead approach.
So let's ask the question nobody wants to hear; Would it be economically wiser to enter into more layers of solutions, securing email at the technical and policy level (1), or to take a GDPR-like approach of bolstering the rule of law?
Let's be clear - this would mean taking NSA, GCHQ, Google, Microsoft etc to court, fining and if necessary dismantling the assets of those who interfere with private communication. It would mean stripping ISPs of listening taps, and auditing server rooms. It would mean something approcimating to a civic cyber police force acting IN THE INTERESTS of the public, rather than against us.
I realise how naive that sounds in this cynical epoch. But I think the ultimate cost of 'zero-trust' society may greatly outweigh the political cost of using the Rule of Law to re-establish 'trusted' networks.
Can't we give the law a chance?
This is the nub of it. People don't know what they want from technology. Or rather, they are conflicted. Our collective illusion that rational technical concerns drive technology hides the reality that all digital technology is a set of power relations that help or hinder different spheres of interest - often within the same group or individuals. Many people want to do bad things and we have even created laws that insist people do bad things (as piss poor solutionism to the original bad things). Hole, spade, keep digging.
The problem of email can be seen two ways:
1. Bad protocols.
2. Bad actors.
Naturally, as techies we attack (1). Just encrypt it all. Zero trust. Train everybody to use encryption. Enforce it. Let's call that the "Rule of Tech".
By contrast, let's call (2) the "Rule of Law". There are already more than enough laws that deal with the fundamental immorality of reading someone else's private correspondence. However we have carved out so many exceptions, including those in the interests of our own profits, that we now just assume (2) is an intractable feature of the world. It isn't.
Email has shown us time and time again that the solutionism of getting people to use encryption is nigh-on impossible. Even the US government have pretty much said PGP is a dead approach.
So let's ask the question nobody wants to hear; Would it be economically wiser to enter into more layers of solutions, securing email at the technical and policy level (1), or to take a GDPR-like approach of bolstering the rule of law?
Let's be clear - this would mean taking NSA, GCHQ, Google, Microsoft etc to court, fining and if necessary dismantling the assets of those who interfere with private communication. It would mean stripping ISPs of listening taps, and auditing server rooms. It would mean something approcimating to a civic cyber police force acting IN THE INTERESTS of the public, rather than against us.
I realise how naive that sounds in this cynical epoch. But I think the ultimate cost of 'zero-trust' society may greatly outweigh the political cost of using the Rule of Law to re-establish 'trusted' networks.
Can't we give the law a chance?
> Can't we give the law a chance?
No because law makers have at every turn attempted to undermine encryption. What makes you think they'll suddenly fine and/or dismantle the assets of the NSA/GCHQ? These are the agencies that have been central to both countries' security in times of war. Times of war that seemingly has never ended.
No because law makers have at every turn attempted to undermine encryption. What makes you think they'll suddenly fine and/or dismantle the assets of the NSA/GCHQ? These are the agencies that have been central to both countries' security in times of war. Times of war that seemingly has never ended.
I think one should not confuse support for the Rule of Law with
exasperation at the parochial "lawmakers" who are poorly educated,
motivated by power and money, and thus essentially traitors to the
principle. That would be cynicism.
>Even the US government have pretty much said PGP is a dead approach.
I would be very interested in a reference to that...
I would be very interested in a reference to that...
So would I , but I can't find it so you'll have to do your own
digging. It was posted here on HN about 3 weeks ago. It was a report
by a major TLA announcing a significant revision of cybersecurity
"best practices", one of which was to stop pushing email encryption as
it's deemed more trouble than it's worth.
Found it at last.
It's back on the front page of HN
https://news.ycombinator.com/item?id=30530592
It's the Whitehouse.
It's back on the front page of HN
https://news.ycombinator.com/item?id=30530592
It's the Whitehouse.
You're starting down a very interesting/sanguine line of questioning, but you're leaving out another complication of "bad actors". The number of sysadmins and netops out there is very large. While some certainly are malicious or are motivated by privacy-violating desires (whether organizational or personal), many of them are just overworked, underpaid, or underqualified. When it comes to email, a single unencrypted link is all it takes to break the trusted chain of Email. Given the sheer multiplicity of the problem, IMO a GDPR-like approach would meet too much pushback from organizations who already don't want to hire a sysadmin.
In this case the reason why I think it's worth focusing on the protocol is that, when an E2E encrypted protocol is designed properly, it removes an entire attack surface and significantly decreases the amount of possible human error. I think encrypted L7 overlay networks are a good solution to step aside these problems at the cost of a bit of overhead (wrapping packets, etc)
In this case the reason why I think it's worth focusing on the protocol is that, when an E2E encrypted protocol is designed properly, it removes an entire attack surface and significantly decreases the amount of possible human error. I think encrypted L7 overlay networks are a good solution to step aside these problems at the cost of a bit of overhead (wrapping packets, etc)
> many of them are just overworked, underpaid, or underqualified.
Absolutely. I didn't mean to seem uncharitable to the average sysop. We've all been there. In fact this state of affairs means that clear legal frameworks, simple messaging that everyone understands, could be powerful. Bad actors mainly exist at a higher level. Over-stretched people in moral grey areas benefit from clear reasons to act decisively, which is why we make sure soldiers get unambiguous orders.
If all sysadmins and developers knew they could go to jail for reading or enabling another to read private communications sent with a reasonable expectation of confidentiality, we'd be in a very different place.
Unfortunately we've let this slip, and entered a cultural interregnum in which we kinda expect emails to be read by others, and even assume they will be. That's not okay. Because even if we fix-up the protocol level there's a residual expectation that it's alright to work around it "because we need to read peoples' emails", right?
> I think encrypted L7 overlay networks are a good solution to step > aside these problems at the cost of a bit of overhead (wrapping > packets, etc)
Yes, I absolutely agree with you. If email can be fixed it has to happen at a whole new "Tor for email" level. Hell, maybe we could all start running our servers as open relays again, given that we'll not know exactly what we are routing.
But I think the law has a part to play. If only to kick-start the initiative to secure email, because right now the surveillance capitalists and spooks are entrenched in a criminal mind-set. Caveat Dolev-Yeo notwithstanding, one can't build trustworthy systems on that culture however good the tech.
Absolutely. I didn't mean to seem uncharitable to the average sysop. We've all been there. In fact this state of affairs means that clear legal frameworks, simple messaging that everyone understands, could be powerful. Bad actors mainly exist at a higher level. Over-stretched people in moral grey areas benefit from clear reasons to act decisively, which is why we make sure soldiers get unambiguous orders.
If all sysadmins and developers knew they could go to jail for reading or enabling another to read private communications sent with a reasonable expectation of confidentiality, we'd be in a very different place.
Unfortunately we've let this slip, and entered a cultural interregnum in which we kinda expect emails to be read by others, and even assume they will be. That's not okay. Because even if we fix-up the protocol level there's a residual expectation that it's alright to work around it "because we need to read peoples' emails", right?
> I think encrypted L7 overlay networks are a good solution to step > aside these problems at the cost of a bit of overhead (wrapping > packets, etc)
Yes, I absolutely agree with you. If email can be fixed it has to happen at a whole new "Tor for email" level. Hell, maybe we could all start running our servers as open relays again, given that we'll not know exactly what we are routing.
But I think the law has a part to play. If only to kick-start the initiative to secure email, because right now the surveillance capitalists and spooks are entrenched in a criminal mind-set. Caveat Dolev-Yeo notwithstanding, one can't build trustworthy systems on that culture however good the tech.
> Absolutely. I didn't mean to seem uncharitable to the average sysop. We've all been there.
Hehe I've met some pretty self-important sysops so let's not be too charitable here ;) (just a joke!)
> Unfortunately we've let this slip, and entered a cultural interregnum in which we kinda expect emails to be read by others, and even assume they will be. That's not okay. Because even if we fix-up the protocol level there's a residual expectation that it's alright to work around it "because we need to read peoples' emails", right?
Is this specifically an email thing? There's a weird culture I've encountered in older organizations that place a lot of emphasis on networks owned by an organization. The organizations themselves seem to have almost a fetish for controlling data that goes across their networks and likewise their net/sysops partake in this culture of absolute control. Maybe it's the same people who are incensed today that social media can act like a safe harbor. Maybe it comes from a time where the cost of sending/receiving a packet was legitimately quite expensive. I'm not sure. I'm glad that most modern attitudes on network management have given up the idea that owning a network means total control of every packet that enters and exits it.
> Yes, I absolutely agree with you. If email can be fixed it has to happen at a whole new "Tor for email" level. Hell, maybe we could all start running our servers as open relays again, given that we'll not know exactly what we are routing.
There are a whole bunch of projects in this space. Everything from overlay networks (Yggdrassil, Zerotier, Tailscale) to mixnets (like Nym) to remailers (like Bitmessage.) We just need to spread the word.
> If all sysadmins and developers knew they could go to jail for reading or enabling another to read private communications sent with a reasonable expectation of confidentiality, we'd be in a very different place.
> But I think the law has a part to play. If only to kick-start the initiative to secure email, because right now the surveillance capitalists and spooks are entrenched in a criminal mind-set. Caveat Dolev-Yeo notwithstanding, one can't build trustworthy systems on that culture however good the tech.
I'm a big fan of this idea FWIW. I just think, realistically, adoption will be slow as small ISPs and organizations throw temper tantrums about how they're being steamrolled by Big Tech and use than as an excuse to both read/intercept traffic and to offer subpar QoS to their customers. There's only so much to be gained by suing a tiny ISP in Florida that is sending mail in the clear because they downsized their netops staff years ago and now they still serve 5 elderly customers who don't want to switch through the occasional contractor.
Hehe I've met some pretty self-important sysops so let's not be too charitable here ;) (just a joke!)
> Unfortunately we've let this slip, and entered a cultural interregnum in which we kinda expect emails to be read by others, and even assume they will be. That's not okay. Because even if we fix-up the protocol level there's a residual expectation that it's alright to work around it "because we need to read peoples' emails", right?
Is this specifically an email thing? There's a weird culture I've encountered in older organizations that place a lot of emphasis on networks owned by an organization. The organizations themselves seem to have almost a fetish for controlling data that goes across their networks and likewise their net/sysops partake in this culture of absolute control. Maybe it's the same people who are incensed today that social media can act like a safe harbor. Maybe it comes from a time where the cost of sending/receiving a packet was legitimately quite expensive. I'm not sure. I'm glad that most modern attitudes on network management have given up the idea that owning a network means total control of every packet that enters and exits it.
> Yes, I absolutely agree with you. If email can be fixed it has to happen at a whole new "Tor for email" level. Hell, maybe we could all start running our servers as open relays again, given that we'll not know exactly what we are routing.
There are a whole bunch of projects in this space. Everything from overlay networks (Yggdrassil, Zerotier, Tailscale) to mixnets (like Nym) to remailers (like Bitmessage.) We just need to spread the word.
> If all sysadmins and developers knew they could go to jail for reading or enabling another to read private communications sent with a reasonable expectation of confidentiality, we'd be in a very different place.
> But I think the law has a part to play. If only to kick-start the initiative to secure email, because right now the surveillance capitalists and spooks are entrenched in a criminal mind-set. Caveat Dolev-Yeo notwithstanding, one can't build trustworthy systems on that culture however good the tech.
I'm a big fan of this idea FWIW. I just think, realistically, adoption will be slow as small ISPs and organizations throw temper tantrums about how they're being steamrolled by Big Tech and use than as an excuse to both read/intercept traffic and to offer subpar QoS to their customers. There's only so much to be gained by suing a tiny ISP in Florida that is sending mail in the clear because they downsized their netops staff years ago and now they still serve 5 elderly customers who don't want to switch through the occasional contractor.
I'm trying to put aside more time to get into Yggdrassil
It has a desirable side-effect of getting me into IPv6 with a positive attitude after successfully putting it off for 20 years. Cheers.
It has a desirable side-effect of getting me into IPv6 with a positive attitude after successfully putting it off for 20 years. Cheers.
Few random notes from my heart:
- it's about time people rediscover that emails are not webmails, even if except for few "geeky" modern MUA the real development of MUA is stuck at '90s level emails can and should be perfectly locally synced, accessed, sent and used in the more broad sense;
- I do not care about "secrecy" of my mails simply because I do not mail myself normally but third parties, since I have no control on them, no knowledge of their systems I can only assume that my messages will be public anyway. Yes, as many I have few friends with GNUPG keys, cross-signed in various occasions etc, but that's just "for fun", not for real usage simply because if GNUGP/PGP became a widespread habits anyone took it's almost useless: I do not have to discuss anything really secret via mail with some friends. At maximum I might have to privately contact third parties signaling a vulnerability, but in most cases those parties do not have a public key either...
- even if we arrive en masse to local/classic mail usage, with IMAP sync-ed maildirs, locally indexed, locally used etc, encryption can be useful ONLY if the system it live on can be trusted. Using a "safe" system on a proprietary OS on top of proprietary hw is not much different than mounting a super-strong door on a very fragile wall, a thief just need to detach the door from the wall without really facing it.
- it's about time people rediscover that emails are not webmails, even if except for few "geeky" modern MUA the real development of MUA is stuck at '90s level emails can and should be perfectly locally synced, accessed, sent and used in the more broad sense;
- I do not care about "secrecy" of my mails simply because I do not mail myself normally but third parties, since I have no control on them, no knowledge of their systems I can only assume that my messages will be public anyway. Yes, as many I have few friends with GNUPG keys, cross-signed in various occasions etc, but that's just "for fun", not for real usage simply because if GNUGP/PGP became a widespread habits anyone took it's almost useless: I do not have to discuss anything really secret via mail with some friends. At maximum I might have to privately contact third parties signaling a vulnerability, but in most cases those parties do not have a public key either...
- even if we arrive en masse to local/classic mail usage, with IMAP sync-ed maildirs, locally indexed, locally used etc, encryption can be useful ONLY if the system it live on can be trusted. Using a "safe" system on a proprietary OS on top of proprietary hw is not much different than mounting a super-strong door on a very fragile wall, a thief just need to detach the door from the wall without really facing it.
I personally have no reason to encrypt my emails. I treat the vast majority of them as potentially public information since I work for a research institute and think that I should be and need to be accountable for anything I do at work. Whether private or work-related, I generally don't write anything in emails that I wouldn't also be willing to defend in person in front of an audience.
I totally agree, for that I’m sending encrypted emails also with my family and I wrote a quick tutorial on how to do it on Apple devices. https://giuliomagnifico.blog/tutorial/2021/01/13/ios-smime-a...
There are a few a real problems with encrypted email.
Spam detection is much more effective when you have access to the plain text of email as you can both build out better models of "this is spam" based on your entire customer base marking things that you miss or get wrong.
You also get to more trivially go "oh this email is only (say) 60% likely to be spam, but it was also sent to 200k people who have no relationship, so maybe it's closer to 90% spam".
The real killer is financial, all the "free" mail providers are making money from hosting your email. Gmail is especially egregious in this regard, and scans the content of inherently private communication in order to build out it the google surveillance infrastructure. Gmail's scanning is why companies like amazon no longer include actual order information in the emails that they send out.
A true E2E mail system (in which email was decrypted on the client side), would run counter to the googles goals for gmail.
Spam detection is much more effective when you have access to the plain text of email as you can both build out better models of "this is spam" based on your entire customer base marking things that you miss or get wrong.
You also get to more trivially go "oh this email is only (say) 60% likely to be spam, but it was also sent to 200k people who have no relationship, so maybe it's closer to 90% spam".
The real killer is financial, all the "free" mail providers are making money from hosting your email. Gmail is especially egregious in this regard, and scans the content of inherently private communication in order to build out it the google surveillance infrastructure. Gmail's scanning is why companies like amazon no longer include actual order information in the emails that they send out.
A true E2E mail system (in which email was decrypted on the client side), would run counter to the googles goals for gmail.
Just use Tutanota (€1/month) or Proton (€5/month) and be done with it. They even have free versions if you don't have your own domain.
What I'd love to see, though, is that organizations (banks, authorities, etc.) start using such systems as well so that they can actually send documents e2e encrypted.
What I'd love to see, though, is that organizations (banks, authorities, etc.) start using such systems as well so that they can actually send documents e2e encrypted.
Ok, how do I force those I communicate with to do the same?
Email encryption needs to be standardized and available in common email clients. A few proprietary providers is not a real, effective substitute.
But of course, the privacy invading "free email" providers would never play along with this.
Email encryption needs to be standardized and available in common email clients. A few proprietary providers is not a real, effective substitute.
But of course, the privacy invading "free email" providers would never play along with this.
I wrote about email privacy in general a few days ago and after talking to a few friends who have read the article they asked about actual email privacy - what happens to the content (my article was mostly focused around obscuring your real address and I don't talk about securing the contents of the emails).
The problem when approaching the issue especially with not-so-technical people is the difficulty of explaining how encryption would work in this scenario. Unlike Signal where a user A sends a message to a user B and the transmission is encrypted because they are using the same protocol, email is a bit trickier to explain. It would be like sending a Telegram message to Signal. Someone needs to do some conversion from one to another. Even when they use encryption, the methodology applied to encryption can be different.
So while I agree with "we should use encryption by default" for non-technical users, this isn't as straightforward. The top comment highlights an issue of the current "send a link to their server" approach, which is what Tutanota uses for example. Everyone moving on to encrypted emails would entail a mass education of users to use PGP keys for example, managing the keys themselves, understanding encryption at rest and the list goes on...
Finally, users are horrible at remembering/maintaining their passwords. Fully encrypted services such as Protonmail and Tutanota (I know proton doesn't encrypt the subject line) do not really offer password resets in the classical way - "Oh I forgot my password, well, here's my phone number give me a new password" or "just send me a reset link to this other email". This means that there is a very real risk of losing complete access to your email address or potentially losing a lot of emails. I believe Protonmail allowed password resets but it would wipe your inbox and Tutanota only allows reset using the account key that you have to generate and save somewhere, but again, a user would need to be aware of this and manage it well...
Great idea. We should. We won't, or at least, the majority won't.
The problem when approaching the issue especially with not-so-technical people is the difficulty of explaining how encryption would work in this scenario. Unlike Signal where a user A sends a message to a user B and the transmission is encrypted because they are using the same protocol, email is a bit trickier to explain. It would be like sending a Telegram message to Signal. Someone needs to do some conversion from one to another. Even when they use encryption, the methodology applied to encryption can be different.
So while I agree with "we should use encryption by default" for non-technical users, this isn't as straightforward. The top comment highlights an issue of the current "send a link to their server" approach, which is what Tutanota uses for example. Everyone moving on to encrypted emails would entail a mass education of users to use PGP keys for example, managing the keys themselves, understanding encryption at rest and the list goes on...
Finally, users are horrible at remembering/maintaining their passwords. Fully encrypted services such as Protonmail and Tutanota (I know proton doesn't encrypt the subject line) do not really offer password resets in the classical way - "Oh I forgot my password, well, here's my phone number give me a new password" or "just send me a reset link to this other email". This means that there is a very real risk of losing complete access to your email address or potentially losing a lot of emails. I believe Protonmail allowed password resets but it would wipe your inbox and Tutanota only allows reset using the account key that you have to generate and save somewhere, but again, a user would need to be aware of this and manage it well...
Great idea. We should. We won't, or at least, the majority won't.
is there any project (probably should be email server) which would use pubkey hash (secp256k1) as identity?
example: `[email protected]`
It would still accept SMTP as backward compatibility and also implement e2e protocol without leaking metadata on side. It could implement other endless cool stuff on top of that (roaming with notifying addresses that you moved to new @example2.com. Send some crypto for better ranking in inbox as optional spam protection.
i did Ask HN about the idea few weeks ago but it did not get traction but there were people who liked idea and dm me in tg/discord, feels like this might be good place to resubmit it.
example: `[email protected]`
It would still accept SMTP as backward compatibility and also implement e2e protocol without leaking metadata on side. It could implement other endless cool stuff on top of that (roaming with notifying addresses that you moved to new @example2.com. Send some crypto for better ranking in inbox as optional spam protection.
i did Ask HN about the idea few weeks ago but it did not get traction but there were people who liked idea and dm me in tg/discord, feels like this might be good place to resubmit it.
You could certainly do that with PGP. That would just be the key fingerprint. You would have to go look up the actual "PGP public key" after that. You could use web key directory (WKD) to make it transparent. Since secp256k1 doesn't support encryption there would have to be a lookup in that case as well.
I like this idea. Eventually we are going to have to come to terms with the fact that there is going to be a ridiculously long number and that number is the identity. We can't hide this fact from the user and hope that things are going to work out.
I like this idea. Eventually we are going to have to come to terms with the fact that there is going to be a ridiculously long number and that number is the identity. We can't hide this fact from the user and hope that things are going to work out.
It would be nice if the page would stick to using HTTPS port 443 exclusively, instead of reaching out to other ports as well and popping up the OS firewall.
Also, Matrix TCP port 8448 is meant for federation, not for client communication.
Also, Matrix TCP port 8448 is meant for federation, not for client communication.
The email encryption tools available are not ergonomic or easy to set-up and maintain. It presents a steep learning curve that requires special plugins or email clients / search tools as the giants don’t have good support for it.
I have a feeling that Gmail could virtually single-handedly make E2E email encryption a standard practice with good UX, but they would rather be able to read your email.
I have a feeling that Gmail could virtually single-handedly make E2E email encryption a standard practice with good UX, but they would rather be able to read your email.
> It's probably worth asking why in 2022, people still don’t use encryption systems to exchange emails,
Because mail MITM is extremely rare. It's much more likely your cell phone texts will get intercepted during 2FA rather than your mail.
And actually, if I had to send an encrypted email, I wouldn't use PGP. I'd send an encrypted zip file.
Because mail MITM is extremely rare. It's much more likely your cell phone texts will get intercepted during 2FA rather than your mail.
And actually, if I had to send an encrypted email, I wouldn't use PGP. I'd send an encrypted zip file.
> I'd send an encrypted zip file.
That itself has a standards problem. Most people don't have anything more than the archive reader installed with the OS which for Windows means nothing better than ZipCrypto is supported IIRC. ZipCrypto can be broken so trivially, that it isn't worth bothering with. 7zip and other tools support stronger methods, even with .zip archives, but many people can't read the result.
There is also the good old key exchange problem as you are using symmetric encryption: you need a second channel to send the key over. Fine for friends and others you already have more than one contact route between, there are a number of ways to communicate after all, but not for general comms. It is scary how many people in a supposedly security aware industry I see sending encrypted archives by mail then sending the password in another mail, or sending the password and a link to the content hosted elsewhere in the same email.
That itself has a standards problem. Most people don't have anything more than the archive reader installed with the OS which for Windows means nothing better than ZipCrypto is supported IIRC. ZipCrypto can be broken so trivially, that it isn't worth bothering with. 7zip and other tools support stronger methods, even with .zip archives, but many people can't read the result.
There is also the good old key exchange problem as you are using symmetric encryption: you need a second channel to send the key over. Fine for friends and others you already have more than one contact route between, there are a number of ways to communicate after all, but not for general comms. It is scary how many people in a supposedly security aware industry I see sending encrypted archives by mail then sending the password in another mail, or sending the password and a link to the content hosted elsewhere in the same email.
I'd send an encrypted zip file.
Good idea but too complicated for the average Joe.
It could be made much easier by building all the necessary steps right into the email client. Just select "Encrypt attachments".
Most of the attempts to address the issue have missed the boat by trying to encrypt the entire email in some non-standardized way.
Good idea but too complicated for the average Joe.
It could be made much easier by building all the necessary steps right into the email client. Just select "Encrypt attachments".
Most of the attempts to address the issue have missed the boat by trying to encrypt the entire email in some non-standardized way.
> In fact, in the daily traffic, as described above, a large percentage of emails is sent “in plain text” without the adoption of cryptographic solutions that protect the content of each message.
I would not expect this to be true. TLS adoption is not universal (and it would be nice to make it so), but I don’t believe it’s that far off it. This hop-by-hop encryption protects the traffic from all but your own email service provider.
Yes, I am misconstruing the article’s intent, which seems to be talking about end-to-end encrypted message content, so that your email service provider can’t see it either, but what it actually says here is just flatly wrong. The messages are sent encrypted (conditions apply), and promptly decrypted by the receiving mail server, so that it can do useful stuff with it rather than just treating it as an opaque blob.
The article completely fails to note the harsh compromises that must be made if you want to further encrypt messages with PGP or S/MIME or whatever. For most people, the most obvious one is that any form of webmail is crippled and you lose all server-side search, meaning that you need to fetch all the mail locally and index it locally. This is normally infeasible for phones.
Fastmail explains the compromises well in this article on why they don’t offer PGP: https://fastmail.blog/advanced/why-we-dont-offer-pgp/. It boils down to (a) it crippling the service, and (b) not actually being useful anyway, because first-party encryption is pretty much unavoidably broken.
Most of what ProtonMail sells as privacy in their encrypted messages stuff is snake oil, plain and simple. As long as they provide the software that holds the keys, they can obtain those keys (this is a style of attack Fastmail refers to in that article—though Fastmail assumes you’d send the key with each request, rather than the email service provider being just a blob store and decryption happening on the client, but changing the code makes exfiltrating that trivial). This is a systemic failing of first-party encryption in the presence of automatic software updates (which is the default on almost all platforms, and fundamental to the web). The only path to real success requires that the platform and the encryption provider be distinct. To ProtonMail’s credit, they have done at least some pushing in the direction of what’s essentially reproducible builds for the web, so that clients can actually reliably detect when something’s changed (subresource integrity is a starting point, but insufficient as it doesn’t protect the top-level resource). I don’t think anything has actually come of it (it’s a fairly tiny niche that there’s not much interest in), but they are trying.
(Disclosure: I worked on Fastmail’s webmail in 2017–2020. I do not believe this has significantly influenced my position on these matters, save that my opinions are better informed than they were before; but I already saw and understood the problems of first-party end-to-end encryption. I find Fastmail’s position in this matter to be eminently reasonable and well-expressed.)
I would not expect this to be true. TLS adoption is not universal (and it would be nice to make it so), but I don’t believe it’s that far off it. This hop-by-hop encryption protects the traffic from all but your own email service provider.
Yes, I am misconstruing the article’s intent, which seems to be talking about end-to-end encrypted message content, so that your email service provider can’t see it either, but what it actually says here is just flatly wrong. The messages are sent encrypted (conditions apply), and promptly decrypted by the receiving mail server, so that it can do useful stuff with it rather than just treating it as an opaque blob.
The article completely fails to note the harsh compromises that must be made if you want to further encrypt messages with PGP or S/MIME or whatever. For most people, the most obvious one is that any form of webmail is crippled and you lose all server-side search, meaning that you need to fetch all the mail locally and index it locally. This is normally infeasible for phones.
Fastmail explains the compromises well in this article on why they don’t offer PGP: https://fastmail.blog/advanced/why-we-dont-offer-pgp/. It boils down to (a) it crippling the service, and (b) not actually being useful anyway, because first-party encryption is pretty much unavoidably broken.
Most of what ProtonMail sells as privacy in their encrypted messages stuff is snake oil, plain and simple. As long as they provide the software that holds the keys, they can obtain those keys (this is a style of attack Fastmail refers to in that article—though Fastmail assumes you’d send the key with each request, rather than the email service provider being just a blob store and decryption happening on the client, but changing the code makes exfiltrating that trivial). This is a systemic failing of first-party encryption in the presence of automatic software updates (which is the default on almost all platforms, and fundamental to the web). The only path to real success requires that the platform and the encryption provider be distinct. To ProtonMail’s credit, they have done at least some pushing in the direction of what’s essentially reproducible builds for the web, so that clients can actually reliably detect when something’s changed (subresource integrity is a starting point, but insufficient as it doesn’t protect the top-level resource). I don’t think anything has actually come of it (it’s a fairly tiny niche that there’s not much interest in), but they are trying.
(Disclosure: I worked on Fastmail’s webmail in 2017–2020. I do not believe this has significantly influenced my position on these matters, save that my opinions are better informed than they were before; but I already saw and understood the problems of first-party end-to-end encryption. I find Fastmail’s position in this matter to be eminently reasonable and well-expressed.)
> The article completely fails to note the harsh compromises that must be made if you want to further encrypt messages with PGP or S/MIME or whatever. For most people, the most obvious one is that any form of webmail is crippled and you lose all server-side search, meaning that you need to fetch all the mail locally and index it locally. This is normally infeasible for phones.
Server-side (spam-)filtering would be another victim. (Okay, so in my case my personal filters mostly operate only on the From:/To:/... headers and so wouldn't be affected, but the effectiveness of spam filtering would definitively be reduced somewhat if the spam filter didn't have access to the message text as well.)
Server-side (spam-)filtering would be another victim. (Okay, so in my case my personal filters mostly operate only on the From:/To:/... headers and so wouldn't be affected, but the effectiveness of spam filtering would definitively be reduced somewhat if the spam filter didn't have access to the message text as well.)
Non-anonymous encrypted emails are signed. So anonymous emails from people you don't know could be treated with great suspicion. In practice, widespread email encryption would be an almost complete solution to spam.
What's to stop spammers from just making up identities?
"people you don't know" would would work for whitelisting (i.e. people I don't know wouldn't get whitelisted), but as I need and want to receive the occasional email from random strangers, it's not all that useful a criterion for marking something as certainly spam.
"people you don't know" would would work for whitelisting (i.e. people I don't know wouldn't get whitelisted), but as I need and want to receive the occasional email from random strangers, it's not all that useful a criterion for marking something as certainly spam.
>it's not all that useful a criterion for marking something as certainly spam.
Which is why you would only mark it as probably spam.
Which is why you would only mark it as probably spam.
Also if we actually care about privacy, maybe we should legally enshrine it universally like some countries do?
Putting real legal barrier in place where at least some parties like employers could be swatted would already be improvement.
Putting real legal barrier in place where at least some parties like employers could be swatted would already be improvement.
Email encryption is dead. And a stupid bolt on, poorly implemented fix that email wasn’t designed to handle.
Ditch email and move on to encrypted comms that are end to end.
Ditch email and move on to encrypted comms that are end to end.
There is no reasonable way to encrypt emails.
It’s far too easy to reply to the message without encryption or something of the sort.
Email was never designed to be encrypted.
It’s far too easy to reply to the message without encryption or something of the sort.
Email was never designed to be encrypted.
There are reasonable ways to encrypt email, we just don't have them. PGP is not it, and I think PGP is at least partially responsible for actual working solutions never materializing. The PGP developers are too paranoid to develop a system that actually works. The web of trust is ridiculous overkill for most users, and should have been an option for really paranoid people, not the default. But because of the web of trust there is no good official scalable way to transfer public keys and thus the whole system doesn't work.
Really it should have been integrated into DNS with a MXKS record that points at the keyserver for a domain or something similar. There could even be a default for domains without the MXKS record that you can fall back to (use MX server on a well known port). The keyservers could be verified the same way we verify HTTPS, which is the part where we drop web of trust into the dumpster and switch to a system that has already proven to be scalable and safe enough for regular users. All of this could be seamlessly integrated into mail clients. If you are worried that your keyserver will leak your email addresses you can have it return bogus key material for addresses that don't exist.
Really it should have been integrated into DNS with a MXKS record that points at the keyserver for a domain or something similar. There could even be a default for domains without the MXKS record that you can fall back to (use MX server on a well known port). The keyservers could be verified the same way we verify HTTPS, which is the part where we drop web of trust into the dumpster and switch to a system that has already proven to be scalable and safe enough for regular users. All of this could be seamlessly integrated into mail clients. If you are worried that your keyserver will leak your email addresses you can have it return bogus key material for addresses that don't exist.
There is no reasonable way to encrypt web traffic.
It's far too easy to copy-paste text from a web page into an unencrypted file or something of the sort (like an email).
The web was never designed to be encrypted.
It's far too easy to copy-paste text from a web page into an unencrypted file or something of the sort (like an email).
The web was never designed to be encrypted.
Web traffic reduced to its simplest case happens synchronously between two parties: Me, the client, and the server providing the resource I want to access. Encrypting the communication between those two points breaks various people in-between who want to listen in with varying degrees of legitimacy (others can't listen in on my traffic, but on the other hand I can't e.g. listen in on the traffic of IoT-devices in my home network any more, either), but it doesn't break anything a regular end user might immediately care about.
Mail traffic is different: So that the sender and the receiver don't have to be online a the same time, we also need another intermediate party, i.e. the mail server. (In practice both sender and receiver utilise a mail server as an intermediate party, but here I'm mainly interested with "my" mail server on the receiving side.)
If the mail server's role was purely restricted to being a dumb store-and-forward store to hold any mails that arrive when I'm not online then, that'd be the end of the story, but in practice the mail server also fulfils a few additional functions that only work if the server actually has access to the message contents:
- Easy access from various sorts of mail clients ranging from full computers to phones to (especially for regular users these days) webmail, without having to worry about anything complicated like key management or whatnot - Server-side spam filtering - Server-side search, especially for mobile clients and webmail
Mail traffic is different: So that the sender and the receiver don't have to be online a the same time, we also need another intermediate party, i.e. the mail server. (In practice both sender and receiver utilise a mail server as an intermediate party, but here I'm mainly interested with "my" mail server on the receiving side.)
If the mail server's role was purely restricted to being a dumb store-and-forward store to hold any mails that arrive when I'm not online then, that'd be the end of the story, but in practice the mail server also fulfils a few additional functions that only work if the server actually has access to the message contents:
- Easy access from various sorts of mail clients ranging from full computers to phones to (especially for regular users these days) webmail, without having to worry about anything complicated like key management or whatnot - Server-side spam filtering - Server-side search, especially for mobile clients and webmail
You are absolutely correct. With web traffic encryption, you’re putting ALL your trust in ALL of the root certificates on your system.
And this has about the same number of possible failure points than PGP encrypted emails.
Trick a user into installing a root cert? Game over.
Find an exploit in one of the default, super trusted CAs and get them to issue you a certificate for a domain / with flags you have no business having in (like this has never happened before, I couldn’t quickly find this, but I clearly remeber the day when some major CA issued certificates and let you issue further certificates down the chain, for which the intended use was to allow you to do subdomains on your own, but they worked for any domain at all)? Game over
Nation state? Game over (except Kazakhstan, they chose the path of most resistance with a method that’s trivially defeatee)
Not to mention DPI, which can’t reveal contents, but can reveal what kind of content it is, and from that possibly identify exactly what it is.
HTTPS prevents only the most dumbed-down MITM attacks. Anyone with enough resources and determination will be able to find out exactly what you’re doing on the web without too much trouble.
And this has about the same number of possible failure points than PGP encrypted emails.
Trick a user into installing a root cert? Game over.
Find an exploit in one of the default, super trusted CAs and get them to issue you a certificate for a domain / with flags you have no business having in (like this has never happened before, I couldn’t quickly find this, but I clearly remeber the day when some major CA issued certificates and let you issue further certificates down the chain, for which the intended use was to allow you to do subdomains on your own, but they worked for any domain at all)? Game over
Nation state? Game over (except Kazakhstan, they chose the path of most resistance with a method that’s trivially defeatee)
Not to mention DPI, which can’t reveal contents, but can reveal what kind of content it is, and from that possibly identify exactly what it is.
HTTPS prevents only the most dumbed-down MITM attacks. Anyone with enough resources and determination will be able to find out exactly what you’re doing on the web without too much trouble.
Microsoft actually has ways of preventing that with information labeling. I used to work on company laptop that was using this extensively and it was not possible to copy something from higher to lower confidentiality. At least easily, there was a loophole involving cmd.exe.
Email is fundermentally insecure. What we need is a new protocol entirely, not to pile more stuff on top of it.
One word: https://delta.chat
Can’t public keys be distributed for email, as with any other service: trusting an authority?
Rewrite the email protocol entirely, using crypto by default and MIXING.
What does "MIXING" mean in this context?
I believe they were referring to the concept of a "mix network"[0], in particular the features of anonymous remailers[1].
In fact, we don't need to rewrite the email protocols to add E2E encryption, as Delta Chat has shown; and if backwards compatibility isn't a goal, then everyone could just move over to Matrix, instead of reinventing email.
Implementing something like a mix net for email is actually not that difficult once PGP encryption can be assumed. Basically you'd just need each mail provider to offer a "switchboard" address in a .well-known location (or in the DNS), so that Alice can wrap her message to Bob in an outer layer message that's encrypted using Bob's provider's switchboard address's public key.
This prevents Alice's provider from knowing who specifically she was sending the message to (it would only know which provider). Also, as Alice's message would contain her signature to authenticate it, her provider could use its own switchboard address as the sender, so that Bob's provider wouldn't know it was Alice specifically who sent it.
[0] https://en.wikipedia.org/wiki/Mix_network
[1] https://en.wikipedia.org/wiki/Anonymous_remailer
In fact, we don't need to rewrite the email protocols to add E2E encryption, as Delta Chat has shown; and if backwards compatibility isn't a goal, then everyone could just move over to Matrix, instead of reinventing email.
Implementing something like a mix net for email is actually not that difficult once PGP encryption can be assumed. Basically you'd just need each mail provider to offer a "switchboard" address in a .well-known location (or in the DNS), so that Alice can wrap her message to Bob in an outer layer message that's encrypted using Bob's provider's switchboard address's public key.
This prevents Alice's provider from knowing who specifically she was sending the message to (it would only know which provider). Also, as Alice's message would contain her signature to authenticate it, her provider could use its own switchboard address as the sender, so that Bob's provider wouldn't know it was Alice specifically who sent it.
[0] https://en.wikipedia.org/wiki/Mix_network
[1] https://en.wikipedia.org/wiki/Anonymous_remailer
Is this not going to make stopping spam somewhat of a nightmare?
do smtp clients validate certificates yet?
my Debian postfixes with their default config certainly don't
my Debian postfixes with their default config certainly don't
protonmail
It’s particularly stupid as I then don’t have a copy of the email myself, and they have disabled text selection on the webpage so I can’t even copy and paste it (easily)!
I suppose it ensures that if the recipient isn’t using TLS with SMTP then it’s not sent unencrypted over the wire, but I suspect the vast majority of email servers are using TLS now. If someone hacks my email they have access to it anyway. I wish the system was intelligent enough to turn itself off if the recipient server has TLS, then I could almost support it as a concept.
But if someone is watching your unencrypted connection to your mail server they can just follow the link and then watch the password being sent. So meh, stupid pointless thing.