[Second in a series of several posts about what is needed to make all Internet messaging go encrypted. Again, if the contents of this post sound unoriginal, that's because it isn't original thinking. It does strike me as part of a larger puzzle, however, and some people may not be familiar with all the arguments.]
I have a lot of friends who work in offices where the sysadmins are, somewhat reasonably, hostile to the idea of their users installing or configuring applications on their company machines. Users in such offices have gotten quite used to using their browsers to access web mail and chat systems -- de facto GMail and GTalk -- as well as things like facebook messaging etc. This, and one's smart phone, is many people's interface to the world outside work. Companies still let you do https: to Google even if they won't let you install a chat client locally, so that's what everyone does. (Well, lots of people do http: but never mind that). In any new world where everyone's messages are end to end secure and probably transiting mix networks to prevent traffic analysis, such users are going to have to be accommodated. That means that their end-to-end encryption endpoint is going to have to be on the web server they're talking to. Keys are going to have to be on that machine, because you're not going to be able to install software to use them on your work machine, and even if you could do everything in javascript, you probably have relatively limited trust for the local box and certainly not enough to leave long lived high entropy keys on it. Now, it is relatively easy for such a user to check that the cert for their web mail provider doesn't come from a Bluecoat box -- no one does, but it is kind of feasible. It is relatively difficult for someone to bug your local machine -- hardly impossible, but not something that is supposed to happen without the local system administrator doing something to your machine or a remote bad guy using malware. On the other hand, a company that's hosting your email and chats almost certainly will hand over encryption keys you store with them if the government forces them to, and it is absolutely impossible to know if this has happened. You just have to assume it has in your threat model. It strikes me that the only real solution to handle this for people to replace their "router" (really NAT) boxes on their cable modems with tiny cheap servers that host their email and chats and such. Luckily, the cost of such things has gotten very low -- a Raspberry Pi class machine with a USB thumb drive larger than a GMail quota costs less than a carton of cigarettes or the cheapest monthly Cable TV bill, and such devices will only get cheaper and cheaper in the near term. It is also feasible to make such machines insanely reliable, especially if there's no mechanical disk involved. (I'm of course not the first person by far to make this observation -- the FreedomBox people, among others, have been saying it for several years. The idea is far from original.) Sure, a bad guy can of course break into your apartment, but that's a lot more expensive than simply getting Google or Facebook to hand over all your communications, and hard to do on a "vacuum it all" basis. With appropriate software and a friendly UI, one's Email, IM, remote file storage and similar needs could be easily managed on such a device with no greater difficulty than one faces in using GMail, GTalk, Dropbox etc. That's "just" a question of keeping the user interface easy. Note that, however, this is not merely a requirement and stumbling block -- it is also an opportunity. If everyone has such a box at home, they've got a server, and the kinds of protocols they can participate in to enhance their own security can be a lot more sophisticated. Some additional notes: a) Certainly, the security of a home server device is no greater than that of the underlying software -- mass surveillance through malware is possible. However, I presume that even there, doing so _en masse_ is dangerous to an attacker, since it leaves lots of traces. Also, just as attackers have been improving their game, there are methods that defenders can employ to improve security on such devices with time -- malware is not a foregone conclusion forever, and is in some sense a higher quality problem. b) I'm aware that many ISPs prohibit the use of "servers" on their home customer's networks, but loads of people ignore this. They also used to prohibit (de facto) sharing connections with lots of machines, and the arrival of commercial NAT boxes named "routers" made that policy fade away as though by magic. I think they mostly don't want to have to re-engineer their networks overnight, but in practice I doubt a device hosting your email and some baby pictures is going to alter traffic patterns enough to cause that anyway. c) Even if people are happy using their smart phone to read their home mail instead of their desktop at work, and could be persuaded to run special software on their phone to do so, it would be of benefit for them to have their own server, on their own physical premises, requiring an actual physical entry into their premises to interfere with their security. d) It is certainly the work of a large and sophisticated staff to keep a service like Dropbox or GTalk up and running, but for the most part, there's not much need for maintenance when there's only a single user or a handful, and what is needed can be automated. Encrypted backups are easily traded with friends given the right UI -- it could be as simple as entering in the friend's email address and then later clicking a box in the web interface for "accept", especially if easy key management is around. (I'm aware that the spam problem now requires a huge staff to deal with, but there are potential solutions there as well -- for example, one could just not do SMTP based email at home. More on that in another message at some point.) -- Perry E. Metzger pe...@piermont.com _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
