Hacker News Reader

Comment by Keyframe | Hacker News Reader

Maybe it's time for a new type of email service. Something along the lines of two way auth, private key on cell phone, public on server. Cell phones have cameras now, so you could generate a QR code or something which your auth app could look at and generate a response in order to generate a unique token to gain access to your message(s). On the server side guys could have a deadman switch which would purge all data if not heard from administrators for 12 hours. That way they could delete data and not be in jeopardy of obstructing any government or whomever is seeking to gain access. Bonus points could be had for not hosting in US too.

View on HN

The whole problem with email is the asynchronous thing.

You want to be secure, then it needs to be in such a way that there's minimum reliance on a central server. But in that case, what happens if your local machine (which is both your mailserver and an end client) is offline? Should the email bounce around in the network (like bitmessage does)? Or should you notify the sender with the standard "Mail Subsystem Delivery failure" that we all know and love.

Actually after reading this, I want to seriously sit down and write a spec but if I include the assumption that there is a chance for the end-server/recipient to be offline, it throws everything into chaos.

This is really the crux of it for me. Peer to peer is no good because it requires both parties to be online. The best I've been able to come up with is multiple servers, which work a bit like command and control servers for malware. Sync from client to server. Server replicates to other known servers. When a server is threatened, shut it down. Update server list on remaining servers to let clients know a server is gone. Add a new server and similarly let clients know.

This requires at least 3 servers to be online at any time. It also assumes client-side key gen and encryption. There are a few more subtleties I'm building in, but that's my thinking so far.

How about a client that does the following, but still uses email: A secure attachement creation client.

You type your email into the app, which is just a word processor. When you send it - it saves an encrypted attachment, attaches it to the message and sends via email.

The other party will need the client to read the attachment, and their client will need to connect to a secure central ID entity to confirm they are the recipient client which can open the message.

This is something which I did not think. It's basically like sending truecrypted packets between people. But this doesn't solve one problem - metadata. I still know you sent an email at time X to person P2. Tor's method of onion routing looks quite nice though.

I still know you sent an email at time X to person P2.

We need a giant public "mailstore" where everybody (or at least a large pool of people) put the encrypted messages with encrypted recipient information. Everybody who uses this mailstore gets a copy of every message posted to it, but unless they are the intended recipient with the right private key they can't make heads or tails of it.

Maybe usenet could be drafted into handling it. Usenet already handles terabytes of encrypted data on a regular basis nowadays.

I don't think we can solve meta-data issue any time soon. But I am really disturbed by the slide in the NSA XKeyScore ppt that said "Show me all word documents sent [emailed] from Iran that contain X" -- This is NOT something I can accept any intelligence agency having the capability to do.

Ok, what about a new email spec. That as a part of it sends random noise at random intervals. This makes it hard to determine if you actually sent a mail, or if it was just the noise part of the spec. ...

Wait, that's so wrong. Why don't we just fix our laws. ...

Wait, we will always have bad actors or regimes, do we just design for that?

When you're worried about things at this level, laws are just an external dependency not under your control, i.e. a security hole waiting to be exploited.

Indeed, the nature of email transport is such that security should be somehow enforced while it's not in your domain of total control. It should be presumed all sorts of eyes are looking at your package and should be dealt with accordingly. One approach is to write locally, encrypt and send it. Likewise for receiving - receive encrypted and decrypt locally. Thing is how to make this happen to work unobtrusively for users as well as how to make it work with current infrastructure of users not using encryption. That's the challenge.

NB: All presuming NSA or whoever doesn't have capability to break your encryption scheme. Great addition would be if attempt of breaking in to your package could notify you, but that's not technically possible as far as I know.

I don't think the encryption thing is the problem. I honestly have a hard time accepting that he was unable to provide decrypted content even with a warrant. That pretty much makes this a Swiss bank account for data and you better believe criminals would be all over it. I'd rather go through legal channels to end violations of due process.

I've tried reading:

  http://wayback.archive.org/web/20130530023856/http://lavabit.com/secure.html

But I'm still not entirely clear on what lavabit used to do to encrypt email once it arrived on its servers. As far as I can tell, they still store an encrypted version of the private key, that they can't decrypt with the other data they store: but would be able to decrypt as soon as a user logs in, and supplies them with the password (again).

So while they don't store enough information to decrypt information, at any point when you log in; you provide enough information for them to decrypt all the stored emails.

Additionally, they could store a plaintext copy of all new email. If the mail you receive is already encrypted with something like GPG, the cannot read it, of course.

Reply on news.ycombinator.com