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

161–170 of 190 posts

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

#161

Post by elahd »

FullyFunctional wrote: post #7
gruez wrote: post #5

Earlier quoted context omitted.

>>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.

Which is a common compromise and frankly more useful than the web-of-trust model, as long as users understand the limitation and verify once offline. It's still unclear to me how this works if you use more than one email client.

This seems like a good use case for keybase.io. They've implemented their own proof of concept messaging system, but I have yet to see any third party integrate with the service.

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

#162

Post by oxide »

ComodoHacker wrote: post #154
Muromec wrote: post #114

Earlier quoted context omitted.

In rhe Eastern Europe XMPP is widely used for online drug purchases, even widely than telegram, which unlike XMPP requires burner phone to register.

Is this an argument against any decentralized communications?

No, just an interesting tidbit of information regarding XMPP.

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

#163

Post by oxide »

Muromec wrote: post #114
ebcode wrote: post #109

Earlier quoted context omitted.

>Is there another communication system that is decentralized (...), and is also widely used? XMPP, maybe?

In rhe Eastern Europe XMPP is widely used for online drug purchases, even widely than telegram, which unlike XMPP requires burner phone to register.

Thanks for sharing, that's quite interesting IMO.

I don't see it as a knock against XMPP, just an interesting tidbit of information and an example of a wide-spread use case.

Moral opposition to drug use is irrelevant here, people want to get high and will find ways to do so, I think the usage of XMPP in Eastern Europe is a great example of why cryptography is important, and why everyone should have access to encryption.

The fact that telegram is used in Eastern Europe for drug purchases is very interesting as well.

It's a good thing people know how to use XMPP and can use it at will for anything they wish, including online drug purchases. Which are going to happen regardless of moral opposition, encryption centralization/decentralization, etc.

Like it or not it's a valid use case.

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

#164

Post by qznc »

Certhas wrote: post #145
qznc wrote: post #112

Earlier quoted context omitted.

WhatsApp is an ok substitute for Email in my opinion. Sure, it is not open source and but federated. Signal, Wire, Matrix, etc should catch up in the next years. What do you need from Email that a messenger lacks?

By far the most important: A desktop client that works without a smart-phone. Identity management that is not smart-phone/phone-number based. Better UI for long form messages, including citing previous lines. Better support for adding people to ongoing conversations. UI for conversations per topic rather than per person. Mailing lists, and the ability to filter them to different folders (or equivalent UI elements). F…

> that covers only half of my email usage at most

Yes, I guess that is the way forward. Split email into a set of different applications. Maybe one of them will take over the rest at some point.

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

#165

Post by e12e »

tptacek wrote: post #90
u801e wrote: post #63

Earlier quoted context omitted.

> but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear. There is a draft standard [1] for strict transport security. I'm not sure of its current status though. > 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. Nothing sent during the dat…

That's strict transport security between hops . There's no proposal on the table for end-to-end encryption, or even (so far as I know) for a header that would signal that a message be dropped before it's sent over an unencrypted channel --- right now, servers simply agree between themselves to enforce transport security, with no input from messages.

Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls).

The sender needs a smtp server, usually "their own", and usually (today) supports tls/ssl.

Now the sender_smtp-receiver_smtp needs to enforce encryption. I really think we're at a point where forcing ssl on incoming mail would a) not lose any legitimate email, b) maybe block some spam.

Then, remove support for connecting to mail over unencrypted pop/imap/smtp for mail clients (probably except for localcast, to not break "known secure transport" like an ssh/vpn tunnel).

Since Gmail, outlook.com have effectively broken easy mail federation (oh, look a bad man had your ip a year ago, no mail for you, and no, we won't bounce it with an error, just silently drop it/file it as spam) - we have an oppsto be a bit aggressive in phasing out old rfcs that allow unencrypted smtp/imap/pop over untrusted networks.

I'll happily concede that patching transport security doesn't make email end-to-end secure. Then again, I'm not sure the Web is any better: ssl is hop-by-hop, clients keep a plain text cache on disk, along with a log of meta-data (and servers tend to log a lot of plain text meta-data too), client certificates are being phased out for http2...

Wrapping messages in s/mime or gpg actually looks pretty good by comparison.

Maybe what we need is a suggestion that if you email user+secure@example.com rather than user@ - only email encrypted to User@example.com (with user+secure@ as alt identity...) will get through?

Then muas could check to see if there's a gpg key for user+secure@, given mailto user@, in the directory - and transparently Encrypt by default?

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

#166

Post by dane-pgp »

elahd wrote: post #161
FullyFunctional wrote: post #7

Earlier quoted context omitted.

Which is a common compromise and frankly more useful than the web-of-trust model, as long as users understand the limitation and verify once offline. It's still unclear to me how this works if you use more than one email client.

This seems like a good use case for keybase.io. They've implemented their own proof of concept messaging system, but I have yet to see any third party integrate with the service.

keybase.io is another centralized third party which, like Signal, we should be trying to move away from rather than becoming more dependent on. By relying on the DNS (which is already trusted to make email, keybase.io, and Signal work), every service provider can be in control of the keys they are publishing.

Also, keybase.io, being centralized, isn't as auditable as the DNS, but admittedly there is work being done on both DNSSEC transparency:

http://blog.huque.com/2014/07/dnssec-key-transparency.html

and keybase.io publishing to the bitcoin blockchain:

https://keybase.io/docs/server_security/merkle_root_in_bitco...

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

#167

Post by e12e »

upofadown wrote: post #140

To save some hunting around, here is the description of what is being proposed here: * https://autocrypt.org/examples.html Basically you include your public key in a "Autocrypt:" header line added to all messages you send out. Then encryption transparently happens. So we give up some protection against MITM attacks but get protection against passive surveillance for people who are not willing or able to participate i…

How is this better than signing outgoing email, and default to encrypt to senders who sign their mail?

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

#168

Post by dane-pgp »

peterwwillis wrote: post #55
dane-pgp wrote: post #50

Earlier quoted context omitted.

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

First of all, most messaging platforms today are encrypted, so that rfc wouldn't really apply except to monitoring by the company providing the service, and that's the price you pay for "free stuff on the internet". Second, almost all the "attackers" are nation-states and your ISP. If it's illegal to read your mail, it should be illegal to read your email (simple regulatory fix). That just leaves spy organizations, a…

First of all, some messaging platforms today are End-to-End encrypted, which is in keeping with the thinking behind that RFC. Given that such models of communication are available as "free stuff on the internet", we shouldn't expect anything less than that from now on (and we should be improving email protocols and implementations to offer at least an equivalent level of privacy).

Second, your "simple regulatory fix" is proving to be not so simple in many nation-states, even ones which claim to be democracies, and I don't think we should ignore people's need for privacy and security while we wait for government policy to fix itself. Indeed, if we do not strengthen the level of privacy and security that people enjoy, the job of fixing government policy becomes that much harder.

To give some examples of recent attacks that even non-technical users need to think about (or at least be protected from), consider these:

https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

https://www.washingtonpost.com/news/the-switch/wp/2015/03/30...

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

#169

Post by elahd »

dane-pgp wrote: post #166
elahd wrote: post #161

Earlier quoted context omitted.

This seems like a good use case for keybase.io. They've implemented their own proof of concept messaging system, but I have yet to see any third party integrate with the service.

keybase.io is another centralized third party which, like Signal, we should be trying to move away from rather than becoming more dependent on. By relying on the DNS (which is already trusted to make email, keybase.io, and Signal work), every service provider can be in control of the keys they are publishing. Also, keybase.io, being centralized, isn't as auditable as the DNS, but admittedly there is work being done o…

I'd say that it's only quasi centralized. At its core, keybase is a directory of signed statements posted on social media. Where space permits, these statements include the person's public key. Verifications can be checked directly on Facebook, Twitter, etc. without using keybase, somewhat decentralizing the service. As you mentioned, writing to blockchain pulls keybase further out of the equation.

They're more of a facilitator for other applications -- Signal is a packaged application itself.

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

#170

Post by adn »

Certhas wrote: post #111
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…

I have colleagues and students that don't use smart phones. As much as I agree with your sentiment, the unfortunate truth is that right now there isn't a good drop in replacement that we could move to. Signal is drop in for WhatsApp and I can tell everyone I talk to on WhatsApp to just contact me on Signal instead. What do I tell people to move to from EMail?

I'm a bit late to this, but check out keybase chat. You can sign up on desktop / mobile / whatever you like, and desktop users can even drag and drop to a folder on their computer to share files (with like a 250gb per person limit right now I think), so that gets you a lot of the functionality of email right there.
Post reply on HN