11 ms·

I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where crypto

I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me. The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.

jolux 6y ago
Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?
- mathnmusic 6y ago
  Because there are too many users on SMTP/Email, but not many PGP users to worry about interoperating? I mean, Hey.com shows that people still like SMTP/Email.
  - jolux 6y ago
    Does it? Or does it show that a small number of highly technical users are willing to pay more for a different email experience? It's a bit early to judge their impact on the ecosystem, and I'm skeptical they'll capture a significant user base in the way that Gmail did. People use email because everyone uses email; you're not going to get people to change how they use email entirely. Nobody cares that it's running on SMTP, they care that they can email everyone they know with an email address.
- oconnore 6y ago
  You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack -- and in those cases you want to maintain as much compatibility as possible. "Federated SecureEmail 2.0" would be dead-on-arrival, where "Secure Client on top of bog-standard email" is ever so slightly less DOA. You get to re-use the existing identity/routing system, existing servers, existing authorization, etc.
  - jolux 6y ago
    >You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Why not just toss the whole shebang and rebuild it below that layer? Signal Protocol seems to be pretty successful here. >Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible.
    - toast0 6y ago
      > No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible. You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc.
      - jolux 6y ago
        >You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. That's right. >Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc. This would require changing all the clients.
        toast0 6y ago
        > This would require changing all the clients. Not really, the old clients would never send (or receive) end to end encrypted messages, so they don't need new UI to tell you that. That's the cost of unbounded backwards comptability. If you want to have 100% coverage of email users, changing all clients is part of the deal. But, uhhh, good luck with that. Server based standards are an easier lift --- you could build a standard to require hop to hop encryption on mail and expect that to plausibly gain enough adoption to use over a managable time frame. Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years.
- core-questions 6y ago
  Aren't there specific legal protections for email in some places, distinct from other online communication?
Multicomp 6y ago
I wish to try n help with the dead simple solution. Heck, I wrote myself a wiki doc as one of my hobby projects sometime (posted here unedited so pardon me if its not perfect http://txti.es/ax4tq http://txti.es/ax4tq) for a simple, simple, simple app that would do basically signal over a SMTP-like system, if not SMTP itself for v1 bootstrapping when online, and do simple mesh relaying (ok thats probably an oxymoron) up to 7 hops when offline. I don't feel confident enough to actually try this project yet, but at least I wrote what my ideal chat app would be, oh and came up with the fancy name 'chattaur' for it.
dane-pgp 6y ago
A slightly more realistic "dead simple solution" might be for mail clients to extend their OpenPGP support to include Autocrypt[0] which would allow users to gain some of the advantages of OpenPGP without having to understand any of the details. [0] https://autocrypt.org/ https://autocrypt.org/
- MayeulC 6y ago
  Interesting. In my opinion, this should also contain provisions for storing the private key password-encrypted on the IMAP server.
  - dane-pgp 6y ago
    I think that's what the Autocrypt Setup Message is for: https://autocrypt.org/level1.html#autocrypt-setup-message https://autocrypt.org/level1.html#autocrypt-setup-message
epistasis 6y ago
S/MIME is the closest to dead simple solution, but it requires trusting certificate authorities. It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.
- acdha 6y ago
  Enterprises, at least in the form of the U.S. federal government, have but there are two key drawbacks: 1. At least until recent, Microsoft implemented it as blocking code in the UI thread – open a message and Outlook won't paint until it can verify the cert, access your local key store (hope your token is in a USB port which is 100% reliable), etc. If you thought “Does that mean that revocation checks block the UI until a network process completes?” you're sadly right. 2. Adoption hasn't been enough to be able to ban untrusted senders. This could still be quite useful for, say, a hard requirement that *@example.com must have signatures but it doesn't help with really common phishing tactics like pretending to be a vendor, business partner, etc. 3. You definitely need to get serious about key management because your ability to read your old encrypted email depends on retaining those keys. This is obviously not impossible but it has a cost when you think about the need to store them securely in a manner which can be restored after the inevitable system failures and compromises.
  - toast0 6y ago
    > 2. Adoption hasn't been enough to be able to ban untrusted senders. This could still be quite useful for, say, a hard requirement that *@example.com must have signatures but it doesn't help with really common phishing tactics like pretending to be a vendor, business partner, etc. Preventing forgery of @example.com is nice, but sadly doesn't matter that much, because a message fro "Your Boss" <totallyfake@superscammy.example.org> is just going to show up as Your Boss in the UI with most clients these days, amd Enterprise oriented clients are worse than the norm. The fastest way to see the actual addresses is to just press reply, which is irritating.
    - acdha 6y ago
lallysingh 6y ago
How do you do key exchange?
- eVeechu7 6y ago
  Video chat might be good for this?
  - ifmpx 6y ago
    With the rate that video-based deepfake projects are progressing, video/image-based verification likely won't remain useful for much longer.
thaumasiotes 6y ago
Isn't the "dead simple solution": 1. Write the message. 2. Encrypt the message. 3. Paste the encrypted message into the email client. Your odds of accidentally sending a message in the clear are zero.
- oconnore 6y ago
  Have you ever attempted to get an organization of people to do this reliably?
- TheDong 6y ago
  And now to read and reply to it, someone has to copy it from the email client, decrypt it, edit their replies in inline, re-encrypt it, and paste it in. As the number of people on the email chain approaches 2, the chance of someone accidentally copying+pasting the entire email chain decrypted into a reply reaches shockingly high levels. A painful manual process where the simpler slightly-less painful path works, but results in insecurity happening, are not a good way to make sure security happens.
  - oblio 6y ago
    > As the number of people on the email chain approaches 2, the chance of someone accidentally copying+pasting the entire email chain decrypted into a reply reaches shockingly high levels. Heck, people (myself included) regularly mess up Reply and Reply All :-)
peterwwillis 6y ago
> The “dead simple solution” is to just run the Signal protocol over SMTP I'm pretty sure the dead simple solution is to either use SMTP or Signal and not a frankenstein's monster of both.
codr7 6y ago
You could run any encrypted protocol on top of SMTP/IMAP; been there, done that; the main issue is you need specialized software on both ends to make it work. Still, doing so solves the transport and persistence problems you would otherwise have to deal with.

jolux 6y ago

Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?

mathnmusic 6y ago
Because there are too many users on SMTP/Email, but not many PGP users to worry about interoperating? I mean, Hey.com shows that people still like SMTP/Email.
- jolux 6y ago
  Does it? Or does it show that a small number of highly technical users are willing to pay more for a different email experience? It's a bit early to judge their impact on the ecosystem, and I'm skeptical they'll capture a significant user base in the way that Gmail did. People use email because everyone uses email; you're not going to get people to change how they use email entirely. Nobody cares that it's running on SMTP, they care that they can email everyone they know with an email address.
oconnore 6y ago
You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack -- and in those cases you want to maintain as much compatibility as possible. "Federated SecureEmail 2.0" would be dead-on-arrival, where "Secure Client on top of bog-standard email" is ever so slightly less DOA. You get to re-use the existing identity/routing system, existing servers, existing authorization, etc.
- jolux 6y ago
  >You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Why not just toss the whole shebang and rebuild it below that layer? Signal Protocol seems to be pretty successful here. >Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible.
  - toast0 6y ago
    > No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible. You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc.
    - jolux 6y ago
      >You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. That's right. >Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc. This would require changing all the clients.
      - toast0 6y ago
        > This would require changing all the clients. Not really, the old clients would never send (or receive) end to end encrypted messages, so they don't need new UI to tell you that. That's the cost of unbounded backwards comptability. If you want to have 100% coverage of email users, changing all clients is part of the deal. But, uhhh, good luck with that. Server based standards are an easier lift --- you could build a standard to require hop to hop encryption on mail and expect that to plausibly gain enough adoption to use over a managable time frame. Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years.
core-questions 6y ago
Aren't there specific legal protections for email in some places, distinct from other online communication?

Multicomp 6y ago

I wish to try n help with the dead simple solution. Heck, I wrote myself a wiki doc as one of my hobby projects sometime (posted here unedited so pardon me if its not perfect http://txti.es/ax4tq http://txti.es/ax4tq) for a simple, simple, simple app that would do basically signal over a SMTP-like system, if not SMTP itself for v1 bootstrapping when online, and do simple mesh relaying (ok thats probably an oxymoron) up to 7 hops when offline. I don't feel confident enough to actually try this project yet, but at least I wrote what my ideal chat app would be, oh and came up with the fancy name 'chattaur' for it.

dane-pgp 6y ago

A slightly more realistic "dead simple solution" might be for mail clients to extend their OpenPGP support to include Autocrypt[0] which would allow users to gain some of the advantages of OpenPGP without having to understand any of the details. [0] https://autocrypt.org/ https://autocrypt.org/

MayeulC 6y ago
Interesting. In my opinion, this should also contain provisions for storing the private key password-encrypted on the IMAP server.
- dane-pgp 6y ago
  I think that's what the Autocrypt Setup Message is for: https://autocrypt.org/level1.html#autocrypt-setup-message https://autocrypt.org/level1.html#autocrypt-setup-message

epistasis 6y ago

S/MIME is the closest to dead simple solution, but it requires trusting certificate authorities. It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.

acdha 6y ago
Enterprises, at least in the form of the U.S. federal government, have but there are two key drawbacks: 1. At least until recent, Microsoft implemented it as blocking code in the UI thread – open a message and Outlook won't paint until it can verify the cert, access your local key store (hope your token is in a USB port which is 100% reliable), etc. If you thought “Does that mean that revocation checks block the UI until a network process completes?” you're sadly right. 2. Adoption hasn't been enough to be able to ban untrusted senders. This could still be quite useful for, say, a hard requirement that *@example.com must have signatures but it doesn't help with really common phishing tactics like pretending to be a vendor, business partner, etc. 3. You definitely need to get serious about key management because your ability to read your old encrypted email depends on retaining those keys. This is obviously not impossible but it has a cost when you think about the need to store them securely in a manner which can be restored after the inevitable system failures and compromises.
- toast0 6y ago
  > 2. Adoption hasn't been enough to be able to ban untrusted senders. This could still be quite useful for, say, a hard requirement that *@example.com must have signatures but it doesn't help with really common phishing tactics like pretending to be a vendor, business partner, etc. Preventing forgery of @example.com is nice, but sadly doesn't matter that much, because a message fro "Your Boss" <totallyfake@superscammy.example.org> is just going to show up as Your Boss in the UI with most clients these days, amd Enterprise oriented clients are worse than the norm. The fastest way to see the actual addresses is to just press reply, which is irritating.
  - acdha 6y ago

lallysingh 6y ago

How do you do key exchange?

eVeechu7 6y ago
Video chat might be good for this?
- ifmpx 6y ago
  With the rate that video-based deepfake projects are progressing, video/image-based verification likely won't remain useful for much longer.

thaumasiotes 6y ago

Isn't the "dead simple solution": 1. Write the message. 2. Encrypt the message. 3. Paste the encrypted message into the email client. Your odds of accidentally sending a message in the clear are zero.

oconnore 6y ago
Have you ever attempted to get an organization of people to do this reliably?
TheDong 6y ago
And now to read and reply to it, someone has to copy it from the email client, decrypt it, edit their replies in inline, re-encrypt it, and paste it in. As the number of people on the email chain approaches 2, the chance of someone accidentally copying+pasting the entire email chain decrypted into a reply reaches shockingly high levels. A painful manual process where the simpler slightly-less painful path works, but results in insecurity happening, are not a good way to make sure security happens.
- oblio 6y ago
  > As the number of people on the email chain approaches 2, the chance of someone accidentally copying+pasting the entire email chain decrypted into a reply reaches shockingly high levels. Heck, people (myself included) regularly mess up Reply and Reply All :-)

peterwwillis 6y ago

> The “dead simple solution” is to just run the Signal protocol over SMTP I'm pretty sure the dead simple solution is to either use SMTP or Signal and not a frankenstein's monster of both.

codr7 6y ago

You could run any encrypted protocol on top of SMTP/IMAP; been there, done that; the main issue is you need specialized software on both ends to make it work. Still, doing so solves the transport and persistence problems you would otherwise have to deal with.