5 ms·

Secret decoder rings are cool, but they're not popular and they never will be. Most people just want a glued envelope and a locked mailbox, not ciphertext. If y

Secret decoder rings are cool, but they're not popular and they never will be. Most people just want a glued envelope and a locked mailbox, not ciphertext. If you want to advance the cause of encrypted email for everyone, and you operate a mail server, make sure it sends and accepts encrypted SMTP connections. Which of these 'encrypted email' use cases is the one that's desirable to people with regards to email, using postal mail as an analogy? 1) Letters to you can only be read by you, using a secret decoder ring to ensure that no one else can. 2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it. 3) Letters to you will usually only be read by you, unless the government is spying on you and X-rays the envelope in transit. 4) Letters to you could be read by anybody and that's fine with you, since they're openly written on the back of a postcard by the sender. Loosely, these analogies translate as: GPG is #1, TLS SMTP is #2, SMTP is #3. (There's not really an analogy for #4.) A few years ago, Gmail finally added a simple lock icon summarizing whether an email was encrypted-in-transit or not. SMIME (#1) is green/locked, TLS SMTP (#2) is gray/locked, SMTP (#3) is red/unlocked. This single icon has probably done more to advance the cause of encrypted email than the previous twenty years of PGP/GPG, and the number of red icons in my email has fallen dramatically over time. That feature was discussed on HN at the time (4 years ago, 209 comments): https://news.ycombinator.com/item?id=11067050 https://news.ycombinator.com/item?id=11067050

0xff00ffee 7y ago
> Secret decoder rings are cool, but they're not popular and they never will be. Isn't this kind of a modern version? https://www.yubico.com/ https://www.yubico.com/ As well as : https://google-authenticator.com/ https://google-authenticator.com/
- floatingatoll 7y ago
  Those are both tools for storing a shared secret — one securely, one not so securely. Decoder rings are built upon the principles of a shared secret, but neither product supports "ciphertext" uses innately. You can build ciphertext processes on them, though I would discourage using TOTP secrets as your secret key since most authenticator apps make it difficult/impossible to access the secret key once it's stored (for security reasons).
  - 0xff00ffee 7y ago
    > though I would discourage using TOTP secrets as your secret key since most authenticator apps make it difficult/impossible to access the secret key once it's stored (for security reasons). This is why I have two Yubikeys. But are you suggesting soft tokens (only) are useless?
    - floatingatoll 7y ago
      No.
saalweachter 7y ago
#4 are conversations carried on in comment sections or forums.
nybble41 7y ago
> 2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it. That's not a great analogy because removing a physical letter from your mailbox and opening the envelope leaves physical evidence of tampering. It's also a felony, with a disproportionately severe punishment, if you're not the designated recipient of the letter. Reading an email at rest on a server somewhere leaves no evidence that the content was leaked and is unlikely to be punished. In the absence of physical evidence when a message is intercepted, or practical recourse when the privacy of the communication is violated, I for one would very much prefer option #1—end to end encryption. Frankly if there were a system as easy as GPG for end to end encryption of physical letters, I'd prefer that as well. GPG does clearly have UX issues. The manually curated web-of-trust was a good idea in principle but too much work to really catch on at scale. Encryption needs to be enabled not only by default but unconditionally, with transparent key exchange and some form of automatic, distributed reputation tracking. The system that fixes these issues probably won't be built on top of SMTP or interoperate with existing email clients, if only because encrypted email cannot be made mandatory without breaking compatibility anyway, but it will serve the same function of facilitating asynchronous, long-form written communication.
- floatingatoll 7y ago
  It's enough of an analogy to make the point, though. Most people's needs for letters security are option #2, not option #1. If you can get the email from source SMTP server to destination mailbox encrypted over the wire, then most people don't care if someone could possibly look at it in your mailbox. And, very few people mind that the "lost letters" division of the postal service opens their mail and packages to try and return it to them when something goes wrong. While I understand that in an ideal world, #1 would be perfect — in today's real world, #2 would be better than the often-unencrypted mess we have today. I've seen a lot of personal mail servers that no one set up encrypted SMTP on, and yet their owners have GPG keys published and signed. Transport encryption and end-to-end encryption are not conflicting goals. I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". I'm not interested in building an encrypted utopia that doesn't interoperate with email. Every social network and web forum for the past 20 years has tried to do this, and none of them have replaced email at all. I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. It's not a big ask, and it doesn't prevent GPG from succeeding. But it might have prevented some random person who probably doesn't need ciphertext encryption from wanting to use GPG if they'd realized that option #2 was in place for them, and thus prevented this entire article's UX nightmare at all.

0xff00ffee 7y ago

> Secret decoder rings are cool, but they're not popular and they never will be. Isn't this kind of a modern version? https://www.yubico.com/ https://www.yubico.com/ As well as : https://google-authenticator.com/ https://google-authenticator.com/

floatingatoll 7y ago
Those are both tools for storing a shared secret — one securely, one not so securely. Decoder rings are built upon the principles of a shared secret, but neither product supports "ciphertext" uses innately. You can build ciphertext processes on them, though I would discourage using TOTP secrets as your secret key since most authenticator apps make it difficult/impossible to access the secret key once it's stored (for security reasons).
- 0xff00ffee 7y ago
  > though I would discourage using TOTP secrets as your secret key since most authenticator apps make it difficult/impossible to access the secret key once it's stored (for security reasons). This is why I have two Yubikeys. But are you suggesting soft tokens (only) are useless?
  - floatingatoll 7y ago
    No.

saalweachter 7y ago

#4 are conversations carried on in comment sections or forums.

nybble41 7y ago

> 2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it. That's not a great analogy because removing a physical letter from your mailbox and opening the envelope leaves physical evidence of tampering. It's also a felony, with a disproportionately severe punishment, if you're not the designated recipient of the letter. Reading an email at rest on a server somewhere leaves no evidence that the content was leaked and is unlikely to be punished. In the absence of physical evidence when a message is intercepted, or practical recourse when the privacy of the communication is violated, I for one would very much prefer option #1—end to end encryption. Frankly if there were a system as easy as GPG for end to end encryption of physical letters, I'd prefer that as well. GPG does clearly have UX issues. The manually curated web-of-trust was a good idea in principle but too much work to really catch on at scale. Encryption needs to be enabled not only by default but unconditionally, with transparent key exchange and some form of automatic, distributed reputation tracking. The system that fixes these issues probably won't be built on top of SMTP or interoperate with existing email clients, if only because encrypted email cannot be made mandatory without breaking compatibility anyway, but it will serve the same function of facilitating asynchronous, long-form written communication.

floatingatoll 7y ago
It's enough of an analogy to make the point, though. Most people's needs for letters security are option #2, not option #1. If you can get the email from source SMTP server to destination mailbox encrypted over the wire, then most people don't care if someone could possibly look at it in your mailbox. And, very few people mind that the "lost letters" division of the postal service opens their mail and packages to try and return it to them when something goes wrong. While I understand that in an ideal world, #1 would be perfect — in today's real world, #2 would be better than the often-unencrypted mess we have today. I've seen a lot of personal mail servers that no one set up encrypted SMTP on, and yet their owners have GPG keys published and signed. Transport encryption and end-to-end encryption are not conflicting goals. I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". I'm not interested in building an encrypted utopia that doesn't interoperate with email. Every social network and web forum for the past 20 years has tried to do this, and none of them have replaced email at all. I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. It's not a big ask, and it doesn't prevent GPG from succeeding. But it might have prevented some random person who probably doesn't need ciphertext encryption from wanting to use GPG if they'd realized that option #2 was in place for them, and thus prevented this entire article's UX nightmare at all.