Wandering Thoughts archives

An insight on the purpose of comments: volume control

Comments are an enduringly popular thing in social networking (even, it turns out, in some forms of social networking that don't seem to have them on first appearance). Ostensibly one reason for this is the power of feedback, but that's not a complete answer; as some people have noted you can have feedback without comments as such, especially if you're doing it within a closed system.

I've recently had a realization about a core reason why comments are good within a closed social network: they reduce update volume.

First, let me take a step back. I've wound up thinking that there's generally only so much update volume a given site can support, both for interface reasons and because most people only have so much time for your social network. You want to get as much content in front of people as possible, but you want that content to be interesting content. Uninteresting content invites people to scale back (ie, walk away from your site) just as too much content does.

If your social network is successful, people are going to have conversations with each other somehow (either in comments or in regular entries that go back and forth). This is a good thing, sort of; conversations create volume, but not all conversations are interesting to everyone. Using comments for conversations creates a second class sort of update that avoids bombarding uninterested bystanders with volume. There can be a massive conversation in the comments to some entry and you'll barely notice from the outside.

(The social network would like you to get involved in the conversation, but only if you're going to be genuinely interested. Hence the logic of showing you some recent comments, as places like Facebook and Google Plus do.)

Of course, you don't need comments per se to do this. What you need is some general aggregation mechanism that groups the conversation together and hides most of it; with sufficient cleverness you could do that with threaded entries or something similar. Comments are just the mechanism that everyone understands.

Why you might want multiple keys for disk encryption

For a moment let's go back to the commentator's suggestion for recovering from key loss from my first entry on full disk encryption:

Many systems support multiple keys (e.g. dm-crypt). Just keep one sealed in a safe.

One question you might ask here is why you need (or want to use) a second key for this backup purpose. After all, you can put a copy of your single key in the safe, and it works just as well to decrypt the data (and if you use only a single key you might avoid the multi-key data loss issues).

After thinking about it a bit, the answer I've come up with is that using a separate backup key is safer in certain sorts of real world scenarios, because it lets you safely change your normal key in the field.

Suppose, hypothetically, that you are on vacation with your laptop and you believe that your normal disk encryption key has been compromised; you've been watched while you typed it, you've found a keylogger on your machine, or whatever. You need to immediately change your key in order to maintain security, but if you only have a single key changing your normal key also invalidates the backup key you have locked in your safe at home. With multiple keys and a separate backup key you can change, revoke, or scramble your normal key while still being able to recover your data if the worst comes to the worst.

(In more extreme situations you can revoke or scramble your normal key, the only one you have memorized, and then be able to honestly say that you have no ability to decrypt the disk right now. The other people involved might even believe you.)

Disk encryption, backups, and your threat model

In response to my two entries on some of the problems with full disk encryption, several people have suggested that the answer is backups. At this point I want to note that the EFF's suggestion is specifically not just disk encryption on laptops, but disk encryption on every computer you own. Given this, we now get to talk about the threat model you want to assume, which is computer security terminology for 'what are you worried about and want to prevent?'

One fundamental security constant about backups is that backups need to be as well protected as what they're a backup of, since they are effectively another copy of it. There's no point in locking one copy in a safe if you are just going to leave the other copy out on the lounge table for anyone to read or take. Does this mean that backups also need to be encrypted (with the accompanying risks of total loss of the backups if the decryption key is lost)? That depends on your threat model.

One threat model is specifically concern about data on your laptop when you are out of what you consider a secure place (such as your home). You worry about your laptop being stolen, inspected at the border, and the like, but you don't worry about your laptop being stolen (or seized) while it's home. Another threat model is to worry about computers being stolen even if they are at home (or alternately in the office). In the first threat model, unencrypted backups at home are protected because you're assuming that your home is safe and secure in general. In the second threat model, your home is not secure; unencrypted backups sitting around your home are just as much a risk as an unencrypted computer.

(In an office, you might consider backups on a disk that is physically in your office area to be at risk while backups sitting on a server in the secured machine room to not be at risk, on the grounds that things not infrequently get stolen from offices but almost never from machine rooms.)

Since the EFF is telling people to use disk encryption on all machines, their threat model seems to be much closer to my second threat model than my first one. This means that you need either encrypted backups or some sort of secure in-the-cloud backups. Both have (extra) total loss scenarios over unencrypted backups, so they are not a complete cure for the drawback of disk encryption. You have perhaps reduced your risk but you have not eliminated it; you're still prioritizing non-disclosure over availability.

Sidebar: on requiring backups

If you believe that full disk encryption requires some form of backup in order to be viable, you implicitly believe that full disk encryption is not appropriate for the large portion of the computer-using public that doesn't back their machines up on a routine basis. This holds both for backing up all of the data and for backing up vital portions of metadata. The less obvious, easy, and automated such backups are, the fewer people the system is suitable for.

(Please note that blaming people when they predictably don't back up their machines is not solving the problem. Real security systems are designed for real people, not theoretical ideal ones.)

How to lose your data with full disk encryption the easy way

In the last entry I wrote that some full disk encryption schemes could cause total data loss on occasions other than you forgetting your keys (or having the entire disk die). A commentator then suggested dealing with the key loss problem this way:

Many systems support multiple keys (e.g. dm-crypt). Just keep one sealed in a safe.

Unfortunately, this is a great way to increase your chance of total data loss (in one of the ways that I was thinking of). In fact any time that you see a disk encryption scheme that allows either multiple keys or changing the key you should be very, very wary. To see why, let's ask ourselves how a multi-key scheme can possibly work.

Barring exotic cryptography where you can somehow encrypt data once so that it can be decoded with several different keys (I don't think this is possible but I don't know enough to definitely rule it out), there are only two choices. Either the system stores multiple copies of the data, each decrypted by a separate key, or there is a level of key indirection going on; there is a single master key that decrypts the data and the user-level keys you use simply decrypt the master key. Since multiple encryptions consume space (and IO bandwidth) at a prodigious rate, you can guess which option most systems take.

(Using a master key also allows the system to use a very strong one, with many very random bits. This may be important since the master key is used to encrypt a lot of data.)

Any time you have a master key, one that you the user does not provide directly, the master key has to be stored somewhere. When a master key is stored, damage to just the parts of the disk where the master key lives means that you lose the master key, which results in the usual catastrophic data loss. Axiomatically the master key is not stored all over the disk, which means that damage to less than the full disk will lose the entire disk. How much damage is required depends on the specific master key storage scheme used by your specific disk encryption scheme, in particular how many replicated copies of the master key it keeps.

For obvious reasons, a resilient system should store multiple copies of the master key (and multiple copies of the master key for each individual user-level key, because you may only know a single user-level key). However, there is a rainbow book security tradeoff here; the more replicated copies you have, the harder it is to invalidate a user-level key. Also, only having one copy of the key is simpler for the programmers creating these systems and besides, assuming that reliable storage is someone else's problem is a popular move.

Now let's ask the obvious question: how many copies of the master key does dm-crypt keep? I'm afraid that the best answer I can determine, from the LUKS on disk format specification, is one copy. Possibly effectively less than one, in that it seems that there are two separate disk locations that both have to be intact in order to retrieve the master key for a particular user-level key. This means that you are one unfortunate disk sector error or misdirected write away from total data loss. I would not be surprised if this was typical of full disk encryption software in general, but dm-crypt is the only one I've looked at.

(Misdirected writes happen for various reasons, including kernel bugs.)

Why systems that allow you to change your key are equally problematic and dangerous is because the easiest way to implement this is also to use master key (whether or not the system admits this). With a master key, changing your key simply requires re-encrypting the master key with the new user key. Without a master key, you would need to re-encrypt (ie read and rewrite) the entire disk (and either insure that the re-encryption is not interrupted partway through or handle it somehow).

The drawback of full disk encryption

Via Hacker News I saw that the EFF's suggested New Year's resolution is full disk encryption on every computer you own. When I saw this I did something halfway between wincing and grinding my teeth. The issue is that full disk encryption has a significant downside, and because of this downside choosing full disk encryption is making a much deeper choice than you might think.

The downside is simple: the failure mode for meaningful full disk encryption is catastrophic data loss. If you forget your password it is game over; there is no recovery possible. Whether temporary or permanent, unless and until you remember the encryption password all of your data is gone. There is no secondary access password, no emergency back door, no special rescue mode the way there is with most other security measures.

(Some disk encryption schemes will also cause total data loss on other events, but let's assume that your disk encryption software is perfect.)

Fundamentally, using disk encryption is rainbow book security in that explicitly or implicitly you're choosing non-disclosure over availability, where you would rather risk losing your data entirely than for potential bad people to have access to it. Under some circumstances this is the right decision; for example, if you can easily restore all of the data on your machine from other sources (and especially if the data is sensitive). Under many circumstances it is probably not the right decision; you would rather have less chance of losing the data even if it means that a bad person might get access to it. Certainly the latter is the case for me. I would generally much rather have a bad person have my data (or a copy of my data) than run the risk of losing it; in the long run my data is (much) more valuable than my privacy.

I don't object to people who've considered these issues deciding that full disk encryption makes sense for them and going ahead with it. But I get annoyed when a respected source gleefully advises people to do this without talking seriously about the very real downsides and risks. The EFF does advise you to save your password somewhere, but I don't think that this goes far enough.

(You may think that the risk of forgetting your password is very low. Let me assure you that over the years I have temporarily forgotten or gotten confused over at least my ATM PIN, my Unix login password, and more than one root password, all of which I use all the time. Perhaps I'm unusual, but with frequently used passwords I get to a state where I don't actually think about the password as I enter it and in fact getting jarred into thinking about what the password actually is is a great way to get completely confused about it, much like the centipede and his legs. The less I'm normally aware of the password, the harder it is to recover from this.)