Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Convenient End-To-End Encryption for E-Mail

autocrypt.org

Post reply on HN
Print view View original

41–50 of 190 posts

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

#41

Post by tptacek »

ekianjo wrote: post #32
tptacek wrote: post #27

Earlier quoted context omitted.

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.

Yes, I've used Signal and other messengers, including "IM's", to send things longer than a sentence. And, when I send email to people, if I have something more complicated than a paragraph or two to send, I make an actual document anyways. So what's your argument?

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

#42

Post by [deleted] »

blfr wrote: post #37
lvs wrote: post #33

Earlier quoted context omitted.

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.

[deleted]

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

#43

Post by tptacek »

azernik wrote: post #36
tptacek wrote: post #20

Earlier quoted context omitted.

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.

It's possible that more bona-fide messages are sent every day with WhatsApp than with email, whose stats include (and, at least for me, are dominated by) automated transactional emails. I don't think "network effect" is as powerful an argument as you want it to be.

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

#44

Post by tptacek »

blfr wrote: post #39
tptacek wrote: post #24

Earlier quoted context omitted.

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 recipient…

So keep it, and use it only for rendezvous for better systems, and for the automated transactional bullets that email is principally used for today.

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

#45

Post by peterwwillis »

tptacek wrote: 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…

I don't think we need serious secure messengers, because we mostly don't need to send secure messages.

Email is "mail on the internet". Mail isn't secure. We use mail everywhere for everything. Occasionally there can be some security problems with conventional mail, but they're fairly rare and we tend to get on with life. And if you need to send a secret via the mail, you can do what the military has been doing for 2,000 years and encrypt your message contents. So I agree, we should stop freaking out about mail.

But we need a secure messaging system? We didn't seem to need it for the post. For the average hacker it's nearly impossible to break into modern messaging systems, centralized and encrypted as they are today. And a lot of us live in free societies where repressive regimes don't legally get to spy on our messages.

Now, this will change in 20 years when China starts spreading its form of Communism around the world similar to how we spread Democracy, as more nations will start adopting internet censorship. But as we've seen with a lot of censorship-circumvention technology, the authorities are pretty successful at blocking or banning the means, and providing state-sponsored replacements when they can't effectively do that.

If you want someone to deliver you a secret today, nearly any messaging service will do. If you don't want to rely on a particular central messaging service, you have to go back to PKI or public-key crypto, which nobody wants to do. Basically, we have "good enough" solutions today, and we have better solutions that people can use if they have to. So I don't think a new secure messaging system is warranted.

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

#46

Post by tptacek »

microcolonel wrote: post #28
tptacek wrote: 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…

> 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 prevent secrets from accidentally being sent in the clear. SMTP has the exact same mechanisms, as does IMAP. HTTPS does not protect data at rest, and it doesn't protect data from the service provider, it never promised to. There is functionally no difference b…

You're confusing client-server secure transport with secure messaging, which is not at all the same thing. Yes: you can ensure a specific SMTP (or IMAP) client connection is encrypted with TLS. But email is store-and-forward. What you can't do is ensure that a given message is encrypted at every hop, let alone end-to-end, where only the sender and receiver can read it.

Obviously, that's the point of layering OpenPGP on top of email. But, like I said: that's opt-in, with plaintext as a default. We would never accept that design in a secure messenger system.

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

#47

Post by lvs »

tptacek wrote: post #40
lvs wrote: post #33

Earlier quoted context omitted.

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 a…

An individual server-to-server communication occurs in milliseconds, so the fact that messages do not arrive frequently is completely irrelevant. It's simply because Moxie -- someone likely to be immune to your kind of negativism -- has not seen fit to work on the problem, given that messaging with an asynchronous chat format fits the general trend of user adoption. Someday I suspect he'll come around on it, I hope.

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

#48

Post by anigbrowl »

tptacek wrote: post #24
ekianjo wrote: 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.

I love signal and kinda-sorta agree, but

a) Right now Signal is oriented around your hpone # and while most people have phones, they come at a cost, are less easy to acquire than an email address, and much less anonymous

b) Signal (and slack and so on) organize conversations around individuals and groups, rather than around subject. That's OK for personal contacts (with whom you have conversational context) but not so great for many other contexts where you'd like things structured by subject

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

#49

Post by tptacek »

lvs wrote: post #47
tptacek wrote: post #40

Earlier quoted context omitted.

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 a…

An individual server-to-server communication occurs in milliseconds, so the fact that messages do not arrive frequently is completely irrelevant. It's simply because Moxie -- someone likely to be immune to your kind of negativism -- has not seen fit to work on the problem, given that messaging with an asynchronous chat format fits the general trend of user adoption. Someday I suspect he'll come around on it, I hope.

An individual server-to-server communication happens in milliseconds, but these systems layer on top of existing email clients, which do not have a polling interval of milliseconds.

I wouldn't hold your breath on email crypto from Moxie.

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

#50

Post by dane-pgp »

peterwwillis wrote: post #45
tptacek wrote: 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…

I don't think we need serious secure messengers, because we mostly don't need to send secure messages. Email is "mail on the internet". Mail isn't secure. We use mail everywhere for everything. Occasionally there can be some security problems with conventional mail, but they're fairly rare and we tend to get on with life. And if you need to send a secret via the mail, you can do what the military has been doing for 2…

You might think we mostly don't need to send secure messages, but remember, Pervasive Monitoring Is an Attack (BCP-188):

https://www.rfc-editor.org/bcp/bcp188.txt

Post reply on HN