Live data from Hacker News

Convenient End-To-End Encryption for E-Mail

autocrypt.org

31–40 of 190 posts

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

#31
post #24
post #21

Earlier quoted context omitted.

> almost everyone can use Signal today Except that almost everyone does not. Yet everyone has an email address. I'd say you have to pick your fight. Trying to convert everyone to Signal, even though it will never replace email in what email broadly does and allows, or trying to add encryption to email.

First, I think you'll be surprised to find how many people use Signal Protocol today, since it's been integrated into one of the world's most popular messaging applications. Second, you suggested that we try to retrofit security into email because "it's a standard". My argument, which you haven't rebutted, is that that doesn't matter.

> Second, you suggested that we try to retrofit security into email because "it's a standard". My argument, which you haven't rebutted, is that that doesn't matter.

It matters because you need to use email for about everything. Ever seen a bank asking you to register using your Signal account? Ever seen any government website relying on anything else than Email? It's pretty clear Email is the de facto standard and it matters because people have to use it anyway. So adding security to email is worthwhile no matter if it's not your only way to communicate.

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

#32
post #27
post #22

Earlier quoted context omitted.

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.” At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely va…

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

> It's that we should stop using email pretty much altogether. Like I said: it's archaic

Sorry but have you ever used Signal or any other IM to send anything longer than a few sentences? Email can be as long as you want, and it is totally appropriate when you want to write a longer document.

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

#33
post #29
post #26

Earlier quoted context omitted.

I've seen you as the top commenter on almost every topic of email security, pitching the same arguments. There is significant demand for content-encrypted asynchronous messaging for all routine purposes. Chat apps do not provide the appropriate platform for real world communication of substance, and security is and must be sought by less dismissive developers than you.

Signal Protocol is designed for asynchronous messaging.

OK, so implement a Double-Ratchet protocol for email clients and call it a day. Don't say that no engineering is possible on this problem, as if that isn't a farcical statement.

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

#34
post #27
post #22

Earlier quoted context omitted.

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.” At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely va…

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

I’m pretty sure I want a big searchable archive, though. That doesn’t seem compatible with most of these security-oriented message schemes.

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

#35
post #11

Earlier quoted context omitted.

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.

I guess I'm asking if you've written Signal or any other mode of secure messaging into a contract explicitly, in some kind of sufficient notice clause.

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

#36
post #20

Earlier quoted context omitted.

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.

So we can feel clever for having actually gotten adoption, rather than feeling clever for creating a wonderfully-secure new system that can't compete with the network effect of e-mail.

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

#37
post #33
post #29

Earlier quoted context omitted.

Signal Protocol is designed for asynchronous messaging.

OK, so implement a Double-Ratchet protocol for email clients and call it a day. Don't say that no engineering is possible on this problem, as if that isn't a farcical statement.

The problem is that you can't do it. More precisely, you cannot get people to convert to your encryption scheme. And if you could do it, you could as well convert them to a better protocol altogether.

At least this is how I understand tptacek's argument.

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

#38
post #5
post #3

Here is a description how it works: https://posteo.de/en/blog/new-easy-email-encryption-with-aut...

>>The manual exchange and management of keys – which users often perceive as complicated – is becoming superfluous: Prior to the first encrypted communication, a regular empty email (without content) is sent. With this, the key is transferred in the background. Henceforth, messages can be encrypted automatically. doesn't sound like they solved the key exchange problem. they merely changed it to trust on first use.

There are complementary technologies which largely address the key exchange problem, such as RFC-7929:

https://tools.ietf.org/html/rfc7929

This is already supported by email providers like Posteo since 2015:

https://posteo.de/en/blog/new-posteo-public-key-directory

They also recently added support for Autocrypt itself, as linked above.

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

#39
post #24
post #21

Earlier quoted context omitted.

> almost everyone can use Signal today Except that almost everyone does not. Yet everyone has an email address. I'd say you have to pick your fight. Trying to convert everyone to Signal, even though it will never replace email in what email broadly does and allows, or trying to add encryption to email.

First, I think you'll be surprised to find how many people use Signal Protocol today, since it's been integrated into one of the world's most popular messaging applications. Second, you suggested that we try to retrofit security into email because "it's a standard". My argument, which you haven't rebutted, is that that doesn't matter.

It doesn't help us all that much that a lot of people are using the Signal Protocol since they're using it in several incompatible silos. Whereas virtually all people using email can communicate with each other.

I use the vanilla Signal. I cannot talk to users of Whatsapp Signal.

Also, there is value in email's address scheme. The person@organization.tld format is very convenient for identifying senders and recipients.

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

#40
post #33
post #29

Earlier quoted context omitted.

Signal Protocol is designed for asynchronous messaging.

OK, so implement a Double-Ratchet protocol for email clients and call it a day. Don't say that no engineering is possible on this problem, as if that isn't a farcical statement.

Have you considered that there might be a reason why none of the proposed schemes to retrofit encryption onto email involve double-ratchet protocols, even though all sorts of people come up with new messaging apps that do use double-ratchets? I think it's because it's very painful to accomplish ratchets in store-and-forward email, where the message update frequency is often measured in minutes, not milliseconds.

At any rate: suppose you actually accomplished that. You've still addressed only one of the bullets in my list above. Why bother? If you can get people to adopt new software, get them to adopt Signal, WhatsApp, or Wire.

Post reply on HN