Securing data from prying eyes is pretty much a solved problem. PGP is just as good as ever. So all you need to do to receive communications securely from another person is to create a PGP Private/Public key pair, broadcast your public key (hint — it’s shorter) to anyone who might want to contact you, and then decrypt incoming messages using your private key on the way in.
This only addresses security. Authentication is a separate issue, possibly just as important, and if anything harder to address (because it involves trusting third parties), and I won’t deal with this. Privacy is plenty to deal with right now.
So we’ve heard that secure communications providers are shutting down or destroying their servers rather than surrender to demands from the US government (NSA, FBI, CIA? We don’t know which branch or branches because they’re not allowed to say — lovely, huh?). What demands might these service providers be concerned about?
- Surrender private keys (why would they even have these)
- Install malware on their servers or on users’ machines (why would a secure email provider install any software on its users’ machines?)
- Help surveil users (e.g. notify government agency when a specific user addresses his/her mail)
- Monitor metadata (e.g. while the body of an email might be encrypted, the header information has to be plaintext).
Can you think of other things?
There’s a recent thriller (you probably haven’t heard of it — it tanked at the box office) starring John Cusack called Numbers Station. The idea is that the CIA maintains a network of shortwave broadcast stations that send out encrypted messages to sleeper agents. To do this they need a specially trained cryptographer and a network of highly fortified shortwave transmitters. Or something. It’s a stupid, stupid premise. (But not as bad as 2012.)
Let’s suppose we want to communicate with field agents securely. Well, before leaving HQ our field agent creates a private/public key pair and leaves the public key behind. He/she secretes the private key on his/her person (committing it to memory is probably impossible, so it might be in a tiny subcutaneous LED projector!) and then goes on his/her merry way, having told his/her handlers to post messages on usenet using his/her public key. There’s no other step required.
Now, how do we handle authentication? Hey, I said this wasn’t about authentication! In any event, same way we handle it using any other less secure communication channel. Perhaps authentic messages are agreed to end with “Signed Bob” or “The peanut walks by night”. Doesn’t matter — we’re talking about security not authentication.
How does Double Secret Agent VII find the publicly posted messages on usenet? Any number of ways. Perhaps they’re in messages entitled “but I like wesley” on alt.wesley.crusher.die.die.die. Perhaps they’re embedded in the comment tags of PNG images posted on alt.sex.donkeys. It doesn’t matter.
Heck, you could just use mailinator. Want to email Double Secret Agent VII? Send an email to [email protected] and use the correct key. Done.
The beauty of the usenet example is that thousands of people will be downloading the message accidentally as a matter of course, and the message will be automatically distributed to thousands of servers whether anyone reads it or not. I really don’t know how PRISM, et al, would help against a determined, competent opponent communicating this way. This is probably why PGP had the US Government so riled up back in the 90s.
So, what about losing track of Agent VII? Simple. You’re Control (or whatever). If a communications channel is compromised (e.g. Kaos figures out you’re posting messages as EXIF data in pornographic images and deletes them or posts confusing spam) then Agent VII can use the Control’s public key to phone home. It’s not complicated.
So, here’s my modest suggestion for creating a secure replacement for email that everyone can use, and which can be gradually migrated to.
- set up a standard mail server.
- configure it to bounce any email that appears not to be encrypted using PGP with a message saying “if you want to contact [email protected] then use [email protected]’s public key to encrypt the message and provide your own public key so a secure response can be sent” and provide a link to a web page for securely sending such emails if the person doesn’t want to.
- outgoing emails are decorated with a public key for securely replying to the sender.
- account holders can have any number of handles (“email addresses”) associated with a given public key. They can access their email simply by asking for it. (Either there’s no passwords or everyone has the same password.)
- the server holds public keys so it can send the messages in item 2 (and provide a convenient system for sending the messages).
- Provide a simple to use web-based client for the service (which does all its encryption / decryption client-side) and provide links to a number of alternative open source clients. Make all the clients as transparent as possible.
- Provide a web-based client that deals only in encrypted data. (I.e. requires the user to manually extract and decrypt incoming messages, and encrypt outgoing messages.)
- Pay for all of this by charging a small amount (say $0.01) for each message sent to a user. (This is Bill Gates’s proposed solution to spam from way back, and if we’re going to migrate off email, we might as well cash in that idea.) Any profits could be donated to MSF, or the campaign to drown Jenny McCarthy in cat vomit.
Now, practically speaking, we could use passwords simply to prevent nuisance denial of service attacks, but we’d have absolutely no problem giving those passwords to anyone who showed up to our office in a sufficiently impressive suit, or driving a big enough SUV.
So, this gives us a pretty secure email system that is fairly interoperable with existing email systems (modulo requiring users “outside” the system to opt into using it, at least to contact its users) and which doesn’t hold any private information or keys at all. Heck, it can simply expose all of its data to Google. (Indeed, it could keep its code repositories exposed so that suspicious users could review changes to its codebase.) Now, it can’t be used with idiotic services that send you your login details, but you can either use another email service (e.g. gmail or mailinator) for those or implement a cryptographic bridge (e.g. if you subscribe using an email address prefixed with “insecure-” then it might do the encryption serverside for you.
Note that as described, the system doesn’t conceal metadata. So if [email protected] sends [email protected] orders to assassinate that pesky reporter, the fact that such a communication occurred (if not its content) is stored on the server. Of course, you could use the web client to anonymously send and/or receive the message, and use Tor to avoid leaving too much of a trace of having done that, but it’s kind of inconvenient, so normal people won’t do it very often. A normal person wants an email client that Just Works (this can provide that) and to exchange email with other people (this can get you there).
The proposed system provides end-to-end encryption of message content without the server needing to store any private keys and would allow all key components of the system to run in the browser (and thus have openly inspectable runtime code that could be monitored for changes). But it won’t stop the NSA from hitting you with a $5 wrench until you tell them where you keep your private key.