DaChesserCat's Journal: Truly private email

The problem with modern email systems is that the emails are stored in plaintext. Some systems may use site-wide public/private key encryption but, if a third party gets access to the site's private key, everything is, effectively, plaintext.

So how do we fix this?

Do all encryption/decryption on the client. The client holds the private keys. The server has everyone's public keys. All traffic and stored data is, by default, encrypted.

More specifically:

Messages on this system are more like posts than emails. Responses and the like are other posts. Each post has a unique message ID. If you choose to quote or reference another post, your post would contain a reference to the message ID and what offsets within the message you wish to quote/repeat. Under no circumstances would content be copied from one post to another. The reason for this will become clear in a moment.

You want to create an account on the system. You create a user ID and a public/private key pair. You give the user ID and public key to the system. The private key is kept only on your client system(s).

When you want create a post, you compose it on your client machine, then generate a session key for some shared-key cryptosystem. You encrypt the message with the session key. Then, you send that encrypted data (not the session key) to the system. The system gives you a message ID.

Note: this is how HTTPS works (the actual content is encrypted with a shared-key system, the shared key is encrypted with public keys for transport) and how PGP works (message is encrypted with shared-key system, shared key is encrypted with recipient's public key for security and sender's private key for sender verification).

You then tell the system what user IDs are allowed to view the message. You request (possibly cache) public keys for such people. For each authorized viewer, you encrypt the message's session key with that viewer's public key. You pass the viewer's user ID and the encrypted session key to the server. The system tracks a many-to-many relationship between viewers and messages, with the encrypted session key on the join table.

The data and the session keys are NEVER stored as plaintext. That information is only held on the client system(s).

If someone succeeds in breaking a session key they will gain access to the contents of one, and only one, message. If this message contains a reference to another message they will need to break the (different) session key for THAT message, as well, to see anything in it. This way, you never have ciphertext (an encoded message) and plaintext (decoded data from another message) with which to help break other session keys.

Decoding a session key is unlikely to provide enough information to determine someone's private key. They'd have better luck trying to reverse-engineer it from the public key.

You connect from your client system and tell the server you want to read your email, probably using some kind of public/private key negotiation. The server determines what message IDs you can see. Your client determines whether or not you've seen them (tracking message IDs is ok; most RSS readers do this so that you aren't seeing the same messages over and over again) and downloads the message IDs you choose to see. The server provides you with the public-key-encrypted session key for each message. Your client system has to use the private keys to decode the session keys, allowing you to further decode the messages.

You can see who else can see the message. You don't really know, from that metadata, who wrote it, though. All you can determine is who can see it.

If you have reason to believe that someone's account has been compromised, you can remove that person from the authorized viewers of one or more messages. The system deletes the link between their account and the message, deleting the session key in the process. That way, if someone attempts to use the compromised account info, they'll have access to fewer messages.

It would also be very easy to setup the system so that so-and-so can see this message for 5 days, then the access is auto-deleted. Or you could choose to delete your access to the message. Then, there would be no metadata connecting you to the message, nor any way for the message to become visible if your account was compromised.

Message IDs which have no references to any user IDs would be auto-deleted by the system. That would break any other messages which referred to it. But that's the only way to ensure that one message can't compromise another. The actual information, in one message, which referenced another would be part of the encrypted data, so there would be no way to determine metadata about which messages refer to which.

In this fashion, the system administrators cannot read your mail. Nor can any third party. Even if they have a warrant and/or other court order. They simply don't have any way to access the plaintext. A third party would have to compromise a client system, then use that information to view messages a) that person is allowed to see b) before other people become wise to their being compromised and disconnect that user from their messages

Naturally, this mechanism can also be used to store notes. Post a message which only you can see. Maybe add access for someone else later on.

Gee, I've NEVER emailed myself some information, from a desktop or laptop PC, so that I could access it on my smartphone :-)

If the system can encrypt arbitrary bit-streams of great length, you could use this as a secure data locker. Store pictures, music, videos, whatever. Only give someone else access if you wish. Revoke that access if you wish. Revoke your own access to something shared by someone else. The people managing the system have no mechanism to see what you have stored.

I've NEVER emailed myself a file as a transfer mechanism from one machine to another :-).