Live data from Hacker News

Convenient End-To-End Encryption for E-Mail

autocrypt.org

11–20 of 190 posts

Re: Convenient End-To-End Encryption for E-Mail

#11
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

The email address format is so useful for domain-based identity. We still haven't squared Zooko's Triangle. What is the practical way to get a function like "document was sent with best effort for some legal purpose to a known party"? Are we just stuck with "login to the secure messaging site" emails from our banks?

Since it's incredibly unsafe to open document formats delivered over email in native viewers, we should be opening those documents on the web-based viewers on websites anyways. That's the most important advice we give at-risk users now: don't click.

Re: Convenient End-To-End Encryption for E-Mail

#12
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system.

That's false. There are mechanisms for lost keys revocation. This is already a solved problem.

> Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. We would never accept a new secure messaging system that behaved like that.

So do you have any other email-like system out there, not dependent on a centralized service, that does not leak meta-data?

> * Most email users get their email from a website. Unless you make them install something on all their computers --- and at that point, just get them to install Signal, WhatsApp, or Wire --- "encrypting" their email involves schemes in which those websites can get their plaintext mail.

Can you host your own WhatsApp server? You own Signal server? No. Having your own email account on a VPS is trivial and much lower effort to remain in control of your communications.

The point is that you dont use website to consult your email if you want to move to encryption. And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any app adoption curve.

Re: Convenient End-To-End Encryption for E-Mail

#13
post #12
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

Revocation doesn't provide forward security.

Standards are what we say they are; almost everyone can use Signal today, and we'd be better of spending the effort to make sure literally everybody can than trying to retrofit security onto SMTP email.

Re: Convenient End-To-End Encryption for E-Mail

#14
post #13
post #12

Earlier quoted context omitted.

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

Revocation doesn't provide forward security. Standards are what we say they are; almost everyone can use Signal today, and we'd be better of spending the effort to make sure literally everybody can than trying to retrofit security onto SMTP email.

[deleted]

Re: Convenient End-To-End Encryption for E-Mail

#15
Gah, the thing I truly hate about this website is that it doesn't offer me an answer to the most important question: But what does it do?

I have to scroll down to see the content in the "What is Autocrypt" section. The content was two sentences long and I still didn't understand what does it do (I wondered what's an "email program" in this context). Since there was no additional text to help me out on the homepage, I had to look further.

FAQ page was too technical for such an explanation, implementation status page gave me some genuine idea that this is something related to other OpenPGP products instead of a new OpenPGP product. The third page I tried opening was the "test it" page, which led me to basically nothing out of any use.

And this is not an isolated case, this is more of a rule for project websites. Seriously, figure out a layman term to explain whatever you're representing and slap it on top of your homepage. Nobody cares if you're decentralized or an open standard until we know what is it. "Convenient End-to-End Encryption for E-Mail" made me believe it was a separate OpenPGP implementation, not a set of guidelines.

Just one sentence like "a set of guidelines that make email encryption easier" would make me want to find out more. This way, by the time I found that out, I have already decided to write this out of rage instead of finding out more.

So, here's a plea to the authors of this website and every other project website: Please, tell me what your project does right at the top of your homepage and do not make me chase an answer to that question.

Re: Convenient End-To-End Encryption for E-Mail

#16
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.

Re: Convenient End-To-End Encryption for E-Mail

#17
post #12
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

> That's false. There are mechanisms for lost keys revocation. This is already a solved problem.

This is very dangerously wrong. Revoked keys decrypt old data just fine. Revocation is advisory. Your attacker will choose to disregard that advice and decrypt anyway.

> And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any app adoption curve.

The fact that encrypted email interfaces with plaintext email has resulted in a continuous never ending series of screw ups where the secret data email gets splattered in plaintext across the network. A secure network protocol is only secure if it's incapable of being insecure.

Re: Convenient End-To-End Encryption for E-Mail

#18
post #12
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

on a vps? why? sounds like a great way to make sure at least one entity has access to your mails, encrypted or not, whether you keep your privkey on a diff machine or not

Re: Convenient End-To-End Encryption for E-Mail

#19
post #16
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.

Incomplete fixes only prolong the agony.

Re: Convenient End-To-End Encryption for E-Mail

#20
post #16

Earlier quoted context omitted.

Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.

Incomplete fixes only prolong the agony.

And where by "agony" we mean "innocent people being put at risk".

For what? So we can feel clever for someone having pulled off an elaborate retrofit we didn't expect we could accomplish? That's vanity, not engineering.

Post reply on HN