4 ms·

ELI5 : It is 2019. Why isn't everybody using pubkey crypto for email? i.e., transparent support of: * I publish a public key * Anyone can use it t

ELI5 : It is 2019. Why isn't everybody using pubkey crypto for email? i.e., transparent support of: * I publish a public key * Anyone can use it to send me an encrypted email * I use my private key to read * as a bonus, I sign my email with my private key * anyone can verify with my public key

bitexploder 8y ago
Because it is a giant pain in the rear. Email is never going to be an end to end secure protocol. Period. It’s never going to be transparent. S/MIME could have gotten the world there but email has too much inertia. Ultimately you have to figure out how to trust keys, that turns out to be the hard part. Use Signal.
- waynecochran 8y ago
  I get that "trust" is the hard part, but for a circle of people that I directly know it shouldn't be hard. I wasn't expecting the email protocol to change, just that I (my email client) would send / received cypher text (e.g., base64 encoded). The cypher text would be transmitted just like any other message.
  - Kalium 8y ago
    You're right! Sending and receiving safely encoded and encrypted ciphertext is so easy and straightforward that it should be common by now. Perhaps it could be worth considering that there could be complexities from another angle? Key discovery and management are complex tasks that require a working knowledge of PKI. These are also tasks that can be very dangerous to undertake in ignorance, as even a small mistake can lead to a full compromise. Is it possible that many users find these difficulties highly challenging?
    - josho 8y ago
      > Key discovery and management are complex tasks SMIME simply included the public key with every message. Solving initial discovery could be as simple as using a well known address, e.g.: www.emailprovider.com/.well_known/kalium.pub. As for key management Apple does a good job managing this (e.g. my understanding is that Apple Messages are E2E using keys yet I've never managed on of these keys), other software vendors would need to step up. So, it's not a user problem, but an incentives problem. Companies aren't incentivized to solve this problem. OSS could, but the network effects mean that any solution is dead unless you can get the likes of gmail on board.
      - Kalium 8y ago
        You're right! Those are all excellent solutions to basic discovery and management problems. With that said, is it perhaps worth considering that this could be a scenario where fully automating something is in fact not sufficient? As you so wisely and correctly point to, Apple has made key management work. Yet most Apple users probably wouldn't notice, or know what it meant, if they were told that whoever they were texting had a new key. From experience this is already true of messaging systems like Signal and Wire. Making available documentation that clearly and simply explains the matter and what the user could or should do has, historically, not reliably been a great way of resolving this issue. It might be worth considering that there could be more at hand that an onerous task that just needs a smidge of standardization and a pinch of automation - though to be clear you are completely right that both are needed and would be very beneficial. Real security generally needs to involve users understanding and weighing risks. I've yet to see any method to automate that well, though I would love to be shown how I am badly mistaken.
  - stcredzero 8y ago
    I get that "trust" is the hard part, but for a circle of people that I directly know it shouldn't be hard. Pretty much what we thought in the early days of PGP and key signing parties.
josho 8y ago
1. It removes the opportunity for free/cheap email providers to commercialize their users data. 2. It makes it difficult for corporate oversight of employee emails. 3. Privacy is a differentiator only for a tiny fraction of the marketplace. So, there is very little profit incentive to invest the engineering resources to implement easy pub key into email.
- inetknght 8y ago
  1. is a good thing 2. sounds like a strawman; corporate oversight of employee emails is certainly possible and addressable 3. that's the real kicker
  - josho 8y ago
    1. is a bad thing because it means gmail et al will never support an E2E standard, meaning the proposal is DOA. 2. How is it a straw man argument? I'm not saying it isn't possible, rather that it adds more complexity for little business value to companies. Don't get me wrong, I'd love better email security/privacy. I went so far as trying SMIME for a year. I just don't see this situation improving.
detaro 8y ago
The existing tooling is hard to use and not enough people care, nor are made to care (e.g. tons of companies handling data over e-mail, but never really pushed by laws (or by enforcement of laws) to use encryption)
- zzzcpan 8y ago
  I think the reason is simpler than that: big e-mail providers want to read your emails to advertise to you, so they sabotage and oppose end-to-end encryption.
  - detaro 8y ago
    Examples of them doing so?
jcranmer 8y ago
There are several reasons: 1. Key distribution is a difficult problem. Where do you go to look up what the public keys are? The only obvious answer is the email provider, which brings us to... 2. Your email is already in practice secure from everyone except you, anyone with access to your email address, and your email provider. Your IMAP, SMTP, and POP connections are all secured with TLS anyways, and the MX connections between your email provider and your recipients' email providers are likely to be secured with TLS as well if at least one of them is Big Email Provider. (Even if that's not the case, this communication is occurring over the Internet backbone which is generally only tappable by the sorts of people who could probably get into your personal email account via other means anyways--the extra value is probably illusory). 3. Secure email doesn't actually secure any headers. Given that From/To/Date is going to be implicated by SMTP logs anyways, and these are the most useful headers for intelligence analysis, there's not much that oculd have been improved. 4. You lose the ability to do full-text search (or even header search, if you designed it to hide the headers as well). 5. Anti-spam measures become basically impossible with encrypted email; you'd have to push everything client-side, which is going to get annoying when you're trying spam detection on your smartphone for 10x the messages and you have to spend extra time decrypting each one. 6. Deploying any automated public-key infrastructure requires somehow automating the verification process. The verification process that can be automated is "this came from a person who has access to this email account," but the verification process that people want is "this came from the person whose name is associated with this email account," which we don't know how to automate.
- stcredzero 8y ago
  Deploying any automated public-key infrastructure requires somehow automating the verification process. The verification process that can be automated is "this came from a person who has access to this email account," What if all gmail and Microsoft email accounts came with a 4096 bit public key, with an option for the state DMV to verify the public key's association with a driver's license? I'm sure this would come with downsides, but would they be much worse than state DMVs using your gmail account to reset their web app passwords?
mwwaters 8y ago
91% of incoming email to Gmail uses opportunistic TLS. STARTTLS has proposals to harden its security. MTA-STS uses DNS to advertise a domain will always use TLS for email. DANE/DNSSEC is the ultimate solution though that's very ambitious. In practice, most emails between major domains will be encrypted over every public link. Only the two providers and the two parties will know either the contents or the metadata. Whether you can trust the providers is a different discussion. But if you can't trust the companies, then you also couldn't trust most software either. The encrypting and decrypting have to be done somewhere.
- tptacek 8y ago
  Most of the point of MTA-STS is to avoid having to use DANE/DNSSEC --- and virtually none of the major mail providers are DNSSEC-signed.

bitexploder 8y ago

Because it is a giant pain in the rear. Email is never going to be an end to end secure protocol. Period. It’s never going to be transparent. S/MIME could have gotten the world there but email has too much inertia. Ultimately you have to figure out how to trust keys, that turns out to be the hard part. Use Signal.

waynecochran 8y ago
I get that "trust" is the hard part, but for a circle of people that I directly know it shouldn't be hard. I wasn't expecting the email protocol to change, just that I (my email client) would send / received cypher text (e.g., base64 encoded). The cypher text would be transmitted just like any other message.
- Kalium 8y ago
  You're right! Sending and receiving safely encoded and encrypted ciphertext is so easy and straightforward that it should be common by now. Perhaps it could be worth considering that there could be complexities from another angle? Key discovery and management are complex tasks that require a working knowledge of PKI. These are also tasks that can be very dangerous to undertake in ignorance, as even a small mistake can lead to a full compromise. Is it possible that many users find these difficulties highly challenging?
  - josho 8y ago
    > Key discovery and management are complex tasks SMIME simply included the public key with every message. Solving initial discovery could be as simple as using a well known address, e.g.: www.emailprovider.com/.well_known/kalium.pub. As for key management Apple does a good job managing this (e.g. my understanding is that Apple Messages are E2E using keys yet I've never managed on of these keys), other software vendors would need to step up. So, it's not a user problem, but an incentives problem. Companies aren't incentivized to solve this problem. OSS could, but the network effects mean that any solution is dead unless you can get the likes of gmail on board.
    - Kalium 8y ago
      You're right! Those are all excellent solutions to basic discovery and management problems. With that said, is it perhaps worth considering that this could be a scenario where fully automating something is in fact not sufficient? As you so wisely and correctly point to, Apple has made key management work. Yet most Apple users probably wouldn't notice, or know what it meant, if they were told that whoever they were texting had a new key. From experience this is already true of messaging systems like Signal and Wire. Making available documentation that clearly and simply explains the matter and what the user could or should do has, historically, not reliably been a great way of resolving this issue. It might be worth considering that there could be more at hand that an onerous task that just needs a smidge of standardization and a pinch of automation - though to be clear you are completely right that both are needed and would be very beneficial. Real security generally needs to involve users understanding and weighing risks. I've yet to see any method to automate that well, though I would love to be shown how I am badly mistaken.
- stcredzero 8y ago
  I get that "trust" is the hard part, but for a circle of people that I directly know it shouldn't be hard. Pretty much what we thought in the early days of PGP and key signing parties.

josho 8y ago

1. It removes the opportunity for free/cheap email providers to commercialize their users data. 2. It makes it difficult for corporate oversight of employee emails. 3. Privacy is a differentiator only for a tiny fraction of the marketplace. So, there is very little profit incentive to invest the engineering resources to implement easy pub key into email.

inetknght 8y ago
1. is a good thing 2. sounds like a strawman; corporate oversight of employee emails is certainly possible and addressable 3. that's the real kicker
- josho 8y ago
  1. is a bad thing because it means gmail et al will never support an E2E standard, meaning the proposal is DOA. 2. How is it a straw man argument? I'm not saying it isn't possible, rather that it adds more complexity for little business value to companies. Don't get me wrong, I'd love better email security/privacy. I went so far as trying SMIME for a year. I just don't see this situation improving.

detaro 8y ago

The existing tooling is hard to use and not enough people care, nor are made to care (e.g. tons of companies handling data over e-mail, but never really pushed by laws (or by enforcement of laws) to use encryption)

zzzcpan 8y ago
I think the reason is simpler than that: big e-mail providers want to read your emails to advertise to you, so they sabotage and oppose end-to-end encryption.
- detaro 8y ago
  Examples of them doing so?

jcranmer 8y ago

There are several reasons: 1. Key distribution is a difficult problem. Where do you go to look up what the public keys are? The only obvious answer is the email provider, which brings us to... 2. Your email is already in practice secure from everyone except you, anyone with access to your email address, and your email provider. Your IMAP, SMTP, and POP connections are all secured with TLS anyways, and the MX connections between your email provider and your recipients' email providers are likely to be secured with TLS as well if at least one of them is Big Email Provider. (Even if that's not the case, this communication is occurring over the Internet backbone which is generally only tappable by the sorts of people who could probably get into your personal email account via other means anyways--the extra value is probably illusory). 3. Secure email doesn't actually secure any headers. Given that From/To/Date is going to be implicated by SMTP logs anyways, and these are the most useful headers for intelligence analysis, there's not much that oculd have been improved. 4. You lose the ability to do full-text search (or even header search, if you designed it to hide the headers as well). 5. Anti-spam measures become basically impossible with encrypted email; you'd have to push everything client-side, which is going to get annoying when you're trying spam detection on your smartphone for 10x the messages and you have to spend extra time decrypting each one. 6. Deploying any automated public-key infrastructure requires somehow automating the verification process. The verification process that can be automated is "this came from a person who has access to this email account," but the verification process that people want is "this came from the person whose name is associated with this email account," which we don't know how to automate.

stcredzero 8y ago
Deploying any automated public-key infrastructure requires somehow automating the verification process. The verification process that can be automated is "this came from a person who has access to this email account," What if all gmail and Microsoft email accounts came with a 4096 bit public key, with an option for the state DMV to verify the public key's association with a driver's license? I'm sure this would come with downsides, but would they be much worse than state DMVs using your gmail account to reset their web app passwords?

mwwaters 8y ago

91% of incoming email to Gmail uses opportunistic TLS. STARTTLS has proposals to harden its security. MTA-STS uses DNS to advertise a domain will always use TLS for email. DANE/DNSSEC is the ultimate solution though that's very ambitious. In practice, most emails between major domains will be encrypted over every public link. Only the two providers and the two parties will know either the contents or the metadata. Whether you can trust the providers is a different discussion. But if you can't trust the companies, then you also couldn't trust most software either. The encrypting and decrypting have to be done somewhere.

tptacek 8y ago
Most of the point of MTA-STS is to avoid having to use DANE/DNSSEC --- and virtually none of the major mail providers are DNSSEC-signed.