Sea of Troubles

An Interesting Idea for a Internet Service

So I was having a few paranoid thoughts about communicating with people securely, in a way that evades traffic analysis, and provides me ways of using side channels (like web browsing and email) to securely communicate with other people. A secure, addressed version of the CSE lunchboard, if you will.

The traditional way that spies and their shadowy kin have evaded traffic analysis (enemies knowing who’s talking to whom) is using dead letter drops. For those who never read spy thrillers, a dead letter drop is a place where you agree to leave messages for one another. Originally, these started out as being simple static locations (like “hidden under a rock under the third bush on the right”), but eventually evolved into convoluted dynamic protocols.

In the novel The Day Before Midnight, for example, the double-agent Pork Chop uses complicated system where a coded ad in a news paper identifies a certain bookstore. In that bookstore, a piece of paper with a number on it is placed in a copy of a specific book (from memory, Gone With The Wind), that message identifies a car in the parking lot, with a plaid scarf in the window. The message is in a briefcase on the backseat of that car.

This process is obviously far too complicated for all but the most paranoid of uses. But surely, we can use some of the dark magic of modern cryptography to build such a system. Add in a few legal tricks and a bit of secure coding and deployment, and this system could be realistic.

So, here are a few thoughts…

Firstly, the high-level idea. What we’re looking for is a system that allows me to securely communicate with a person or persons without someone unauthorised reading that message, without anyone being able to tell who I’m talking to (and vice-versa). In addition to that, it should be deliberately distributed across multiple legal jurisdictions (so that I can deliberately spread logs of my access across jurisdictions, and protect my information from some of the nastier provisions of the Patriot Act and it’s friends). In addition to this, the system should support an email interface for submissions, so that standard email remailers can be used to protect my privacy.

We can quite easily leverage GPG/PGP crypto to provide confidentiality of messages, and some measure of message identity assurance. This should be the underpinning of the solution. GPG is nice, because the trust model isn’t heirarchical. Unlike X.509, anyone can create a GPG key that’s as valid as any other, using the same cryptographic algorithms as big business and the less sensitive elements of government.

Next step up, we need to work out what and how we’re going to store. We want this to be a web application, and we want it to be fairly simple. In order to make this thing work in a distributed fashion, we need to minimise the barriers to entry. In this case, that means minimising the system requirements. The goal for this project would be to have zero requirement for a database, and be written entirely in a commonly available language. My preference would be Python, but have no substantial objection to PHP (assuming it’s written by someone who understands PHP security - I don’t).

The individual messages should be stored as individual text files, with .htaccess preventing direct access to them (all access should mediated by our script). The filename should be a GUID. It’s probably easiest to use some combination of thee SHA1 and MD5 hash functions, and the time of receipt. Assuming a filesystem with fairly lax namespace restrictions, we would probably save the file as date +%F-%H-%M/sha1sum $file``md5sum $file. In addition, in order to be accepted, messages must be encrypted (otherwise, there’s little point), must be ascii armored, and should be signed.

In order to conserve space and bandwidth, there should be a limit on the size of any individual message, and messages should probably exire after a month. Actually, expiry should be configurable, at least by administrators and probably by the poster as well.

Okay, so we have a way to store messages, now how do we get them in and out. In is easy – allow posting from an html interface, and an email gateway (in the same way RT 3 does). The web interface should use POST in all cases, to ensure that no information is leaked into the apache logs.

But now, the tricky question. Who do we allow to retrieve the messages? This is the last question I can’t decide yet. The easy way out is to allow any person to view any message, or to search by recipient KeyID. This is the easy way, but I’m worried that it would allow some traffic analysis - by getting the list of all messages addressed to that person, we can see if there are any other people whom the message is encrypted to. Given that many people encrypt messages to themselves by default (I do, else I could never read my sent mail), this might allow an attacker to work out who’s talking to whom, at least by keyid (which could then be looked up on the keyservers, if the keys have been publically distributed). At the very least, it would tell you who the recipients of these messages are.

So, now that I think about it, there really is no option here. In order for the system to preserve the level of security against traffic analysis I’m looking for, we can’t allow that. In order to search for message sent to you, you must answer some cryptographic challenge. In order to maximise usability, this challenge-response should be valid for a period of time. At the very least, a session, but I’m tempted to make it more like 2 weeks (in line with gmail), with the response to the challenge stored in the cookie. We need some way of managing recipient keys in order to check their signatures - I wonder if looking in the keyservers and caching the results is sufficient… Anyway, regardless of how it’s done, the response should be a signed version of the challenge, with identifying data (keyid) and time variable data (eg: year-month, or year-month-day).

This idea was partially inspired by the way the Source Code Club (some software-theives-for-hire) communicates with their ‘customers’ - pgp encrypted posts to Usenet, and thinking about some of the ways you could attack that system. I’m tempted to write the damn thing, just as an intellectual exercise, because goodness knows I need some intellectual exercise. So, all these things aside, does anybody think this system would be useful?

I think I’ll call it Crouton, ‘cause they’re little bits of stale data. :)

Until I manage to turn comments on on this blog (with a solution against the comment spammers), please feel free to respond by email to simon dot brown at gmail.com. I’ll respond to comments publically here, unless you ask me otherwise. Speaking of which, I should probably set up TrackBacks as well.