Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> And how useful is it to run your own encrypted email server if the email message itself isn't encrypted in transit?

It isn't, of course.

The proportion of mail that is encrypted is the square of the proportion of email users who have encryption set up (assuming all email users are equally likely to mail any other user). So if 1% use encryption, only 0.01% of emails will be encrypted. If we want most mail to be encrypted we need 70% of people to use encryption. This means it has to be REALLY EASY TO SET UP AND USE.

Ideally, when someone buys a PC/phone/tablet, and uses it to communicate with others, it should do strong encryption out of the box, so that the user would have to take explicit steps to not encrypt.

Most of these devices run software controlled by Microsoft, Apple or Google, all of which are deeply implicated with the NSA. So it's futile to expect that they will willingly protect their users' privacy. Therefore the next best thing is to write software that once installed will be really easy to use, that is to say in normal operation it will take no effort at all to use (zero user interface).



> If we want most mail to be encrypted we need 70% of people to use encryption. This means it has to be REALLY EASY TO SET UP AND USE.

Given most users' utter ignorance about any technical matter (a consequence of the intellectual laziness our age promotes IMHO), I think the only useful way to ensure this is to make it the default in any e-mail client. But this is still only half the way uphill -- it also means storage should also be secure, including remote ones like Gmail, or that users should become educated enough to stop using services that aren't.

The first one is unlikely to happen IMHO, as it would mean companies that depend on mining your e-mail, like Google, would basically have to stop doing it. The other one is even more unlikely to happen as it would require people to actually invest time in using computers, something which our society has constantly brainwashed to think they shouldn't do -- everything should be plug'n'play and trivial and just work out of the box. Heaven forbid you'd actually have to understand the whys and the hows.

Now that our decades-long dream of seeing everyone having access to a computer and to a vast network of information has finally come true, it doesn't look like such a beautiful dream anymore...


> I think the only useful way to ensure this is to make it the default in any e-mail client.

I agree.

> But this is still only half the way uphill -- it also means storage should also be secure

That would be ideal. But even without that, something useful has been done since it is practical for the NSA/GCHQ to read all internet traffic, it is not pratical fro them to burgle everyone's house.

If PCs come with encryption as standard, it needs to be a steganographic file system, with multiple keys revealing different sets of files and with the number of possible keys being very large. Otherwise, an adversary could simply use rubber hose techniques to get the information.

> including remote ones like Gmail

Gmail represents a single point of failure and is thus always going to be attractive to an adversary. Anything stored unencrypted on gmail, Google Drive, or equivalent -- one should assume the NSA can read it.

> The first one is unlikely to happen IMHO, as it would mean companies that depend on mining your e-mail, like Google, would basically have to stop doing it.

You're right in that gmail's business model is basically anti-privacy. We need to convince people to use local email software not store their email on a remote website (such as gmail).

> The other one is even more unlikely to happen as it would require people to actually invest time in using computers

You're right, because it's impossible to have a zero-user interface filesystem encryption (since people need to type in their password).

> something which our society has constantly brainwashed to think they shouldn't do -- everything should be plug'n'play and trivial and just work out of the box.

There's certainly an element of truth to this.

> Now that our decades-long dream of seeing everyone having access to a computer and to a vast network of information has finally come true, it doesn't look like such a beautiful dream anymore...

Computers can be the biggest tool for freedom and empowerment ever invented, or the biggest tool for coercion and oppression. I believe this will be one of the biggest political issues of our times.


Just why isn't key distribution an SMTP extention? I'd expect there to be an RFC for it, but I couldn't find anything. (I'm not talking about DomainKeys. I'm asking why an SMTP client can't ask for a recipient's public key, and if it exists do the encryption.) Here is a blog post about it:

http://www.illuminatedcomputing.com/posts/2013/07/public-key...


There is TLS for SMTP, which admittedly doesn't protect the email once it gets to the server, but at least helps en-route.

Also, I don't think there's a problem around the fact that most of the time you don't communicate directly with the recipient's smtp server - relaying is definitely a part of SMTP. It would work in the case of running your own SMTP server that you use to relay mail (assuming you encrypt your own SMTP sessions), but you'd need smtp servers to recursively query for the public key if you want to enable relaying.

This is starting to sound suspiciously like DNS, so why not just store the keys there? There are already ways to do that:

http://www.gushi.org/make-dns-cert/HOWTO.html

Add in DNSSEC records and you can be pretty certain you have the right key.


Thank you for replying! Relaying does seem like a fatal flaw. DNS seemed like a bad match for per-user information (rather than per-domain), but indeed that HOWTO gives a nice way of working around that. So it's just a question of MUA PGP modules trying that mechanism.


I'm currently writing software that essentially does this. It doesn't put the key in the SMTP protocol, but in the mail header, e.g.

    X-Purrcat-Key: ...public key goes here....


Well I commend you for moving things forward! Have you talked with any security professionals about possible pitfalls of using mail headers? I was sort of hoping tptacek would come on and tell me why my idea is no good. :-)


Not yet, though the project will be open sourced, which will hopefully enable other people to catch any security holes I've left in it.


Please note that the X- pattern is considered deprecated: http://tools.ietf.org/html/rfc6648

TL;DR: just make your header Purrcat-Key.


Thanks for the info.


This seems like it would work if you wanted to encrypt a reply message, however how would you get another user's public key if you're the one initiating the first conversation?


I've always assumed that encrypting my communications is akin to demanding the authorities pay special attention to my activities.


That's why everyone should do it. For everything.


I think defaulting to encryption is great for businesses. A friend who does security policy for a big corporation is always complaining about data egress, and closing even one vector would help. And within the corp you control the MTA and MUAs, so you could at least secure intra-corp communications. To him, leaking info to a competitor or the public is a bigger deal than the NSA.


Absolutely. I implemented 5 regional health information exchanges. We resigned ourselves to accepting that a disclosure was a matter of when, not if.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: