Wandering Thoughts: Recent Entries

The advantage of HDMI for dual displays

One of the interesting things that happened during my five years of hardware hibernation is that when I woke up, even low end (aka passively cooled) graphics cards could suddenly drive two digital outputs. Back in 2006 it was common for cards to have one analog and one digital out (eg, the ATI X300 in my work machine had VGA plus DVI), but getting dual digital out required an expensive card with an often noisy fan.

(I actually went through two such cards at work, each time deciding that I couldn't see enough advantage to driving my second display digitally instead of via analog VGA to be worth putting up with the noise. Possibly I wasn't sensitized enough to VGA artifacts and issues.)

What I have to thank for this is HDMI. Now, I'm aware that there's a lot to dislike about HDMI (see eg HDCP), but from my perspective the great thing about it is that it's given even low end cards a second digital output; it seems to be common for cards to have both DVI and HDMI. Some modern displays can be directly driven over HDMI and for the others, a simple cable will go from HDMI to DVI. And so my 2011 low end, passively cooled graphics card will now drive both my displays at work digitally, one directly with DVI and one with an HDMI to DVI cable, which is something that I never managed nicely before now.

(I believe that this has resolution limits. I don't use really big LCDs, so these haven't affected me.)

One of the interesting questions for me is why this happened. Why did graphics card vendors start putting HDMI on everything, where they only rarely did dual DVI? I think that part of the reason is that HDMI uses a physically small connector. DVI uses a relatively big connector and if you look at the back of a graphics card (especially a dual-DVI graphics card), there just isn't all that much physical space there; it's hard to get two DVI connectors and anything else in. By contrast, HDMI connectors are much smaller (I can't find the exact dimensions, but some sources say a third of the size). This makes it much easier to find the physical room for a HDMI connector on a card edge and on a circuit board.

(For example, my current graphics card just fits in VGA, DVI, and HDMI connectors with basically no spare room.)

PS: I don't think it's a coincidence that DisplayPort, the theoretical next generation replacement for DVI, also has a small connector. I suspect that the graphics card layout designers had a few words with people.

(Of course pretty much everything seems to be going to small connectors, with large ones proving awkward. Consider SATA versus IDE, for example. Someone who knew more about electronics than I do could probably write a fascinating article about all of the developments that made narrow-connector interfaces feasible and preferable to the old wide connector ones.)

What five years of PC technology changed for me

This fall I got a new home machine, just a bit over exactly five years after I got my previous home machine. It happens that I saved the invoice for my five year old machine, so I dug it out today in order to do a comparison about what five years of progress in PC technology did and didn't change for me.

First off, the progress of five years got me much better prices. My recent home machine cost me only about 60% of what my old home machine did. By itself, this is pretty impressive. Apart from that, running down the major components:

• CPU: AMD dual core versus much faster Intel quad core. The Intel CPU was cheaper but not by a substantial amount; I think the AMD was probably closer to the high end at the time. I don't know what the benchmark results are, but I got a substantial performance improvement.

• RAM: This is perhaps the most striking change on a purely numerical level; in 2006 I got 2GB of RAM for more than twice as much as what 16 GB of RAM cost me in 2011. Even in 2006, 2 GB was clearly economizing (I remember debating with myself over 2 GB versus the extra money for 4 GB and deciding that 2 GB should be good enough). In 2011, 16 GB is as much as the motherboard will take with current DIMM densities.

  In short, desktop RAM has become stupid cheap.

  (One index of the change is that in 2006, the 2 GB of RAM cost more than the CPU and was the most expensive single component. In 2011, the 16 GB cost only a bit over half of the CPU.)

• motherboard: the modern era features more SATA, less IDE, more USB, and not even one external serial port. Motherboards are unexciting. Even in 2006 the motherboard had onboard sound and gigabit Ethernet. The 2011 motherboard probably has better onboard sound, but in practice this doesn't matter to me; my sound needs are modest.

  (The 2006 motherboard was a bit cheaper than the 2011 motherboard, but neither were particularly expensive or advanced ones.)

• Hard drives changed only moderately at one level; in 2006 I got 320 GB drives for somewhat over twice what 2011's 500 GB drives cost me. In 2011, 500 GB drives are nowhere near state of the art; in 2006, 320 GB drives were not that far out of it.

  (This was before the floods in Thailand.)

  On another level, they changed a lot. The 320 GB hard drives of 2006 were my only storage. The 500 GB drives of 2011 are only for the operating system; my data lives on a pair of 1.5 TB drives (that I had upgraded to some time ago). 500 GB is way overkill for the OS, but there's no real point in using drives that are any smaller; it's not like I'd have saved any significant amount of money.

• Video card: ATI X800 GT versus ATI HD 5450 with double the memory for less than a third of the price. Toms Hardware theoretically puts these two cards in almost the same performance category, although I'm not sure that's really true. In practice, what happened between 2006 and 2011 is that graphics cards shifted to the point where a basic passively cooled card was clearly more than good enough for what I was doing, even for driving dual displays digitally.

  (I don't yet have dual displays at home, but I do at work and my work machine uses the same card. In fact, my work machine is now a clone of my home machine, just as it was in 2006.)

• optical drives: in 2006 a DVD burner cost about four times what it did in 2011, and I thought I would listen to CDs enough to justify having a separate CD/DVD reader (rather than put wear and tear on an expensive burner).

  (I was wrong; my CD listening had already dropped off a cliff in early 2006 and never recovered. I still kind of miss that sometimes.)

• Power supply: in 2006 I didn't trust the power supply that came with the case to really be a good solid one that delivered enough power so I bought a separate one as well. In 2011 I couldn't find any reason to worry about it so I didn't; the power supply you get with a decent quiet case these days is going to be quite good, more than you need (for a PC like the kind I build), and efficient.

In 2006, the most expensive components were the RAM, the CPU, the two hard drives together, and then the video card. In 2011, the most expensive components were the CPU, the motherboard, and the case (more or less tying with the RAM). Another way to put it is that in 2011, the video card, the DVD burner, the hard drives, and pretty much the RAM were all what I considered trivial expenses in the overall machine.

Understanding a subtle Twitter feature

One part of getting on Twitter has been following people, which led me to discover that when you follow someone Twitter doesn't show you all of their public tweets. To summarize what I think is the rule, Twitter excludes any conversations they're having that purely involve other people you don't also follow. Their tweets in the conversation will appear in their public timeline, but not in your view of their tweets.

(This may only apply to relatively new Twitter accounts, or even only to some of them. I've seen Twitter give two different interfaces to two new accounts.)

On the one hand, when I discovered this I was infuriated. If you really did want to see everything (for example, so you could find other people to follow based on who your initial people had interesting conversations with), this made having a Twitter account worse than just perusing the Twitter pages of interesting people.

On the other hand, once I thought about it more I've come to reluctantly admire Twitter's trick with this feature. What it is, from my perspective, is a clever way to reduce the volume impact of following someone and thus make doing so less risky. Without it, following someone would immediately expose you to both their general remarks and to the full flow of whatever conversations they have. With Twitter's way, you are only initially exposed to people's general remarks; you ramp up your exposure to their conversations by following more people, and ramp it down by the reverse.

My feeling is that exposure to an overwhelming firehose of updates is the general problem of social networking. Social networks usually want you to be active and to follow lots of people. But if those people are themselves active, the more people you follow the more volume descends on you, and it's especially bad when you follow very socially active users, the ones having a lot of conversations. This creates a disincentive to follow people and pushes you to scale back. Twitter has this especially badly because it has no separate 'comment' mechanism (comments are important for reducing volume). Twitter's trick here is thus a clever way to reduce the firehose in a natural way that doesn't require user intervention and tuning; you could see it as a way of recreating something like comments in a system that doesn't naturally have them.

Once I realized this, it's certainly been working the way that Twitter probably intended. When I'm considering whether or not to follow someone I don't really look at the volume of their tweets in general; I mostly look just at the volume of their non-conversation tweets, because those are the only ones that I'm going to see. Often this makes me more willing to follow people (and thereby furthers Twitter's overall goal of getting me more engaged with their service).

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.)

SSH, man in the middle attacks, and public key authentication

Mark wrote a comment on my note about nssh:

A warning about 'StrictHostKeyChecking no' by default. I had the same thought as you did, and tested the behavior. When set to 'no', ssh will connect anyway if the host key changes and you're using public key auth (it will print a warning, and disable password based auth however), which doesn't prevent a man in the middle attack if the person has access to your public key (which it's very likely they will have).

I looked at that and said 'that can't be entirely right; access to your public key shouldn't make any difference'. But intuition is a bad guide to security and cryptography, so I went off to read up on the SSH-2 protocol RFCS to see for myself (or at least skim through them). The result was interesting and comes to a stronger conclusion than I was expecting: I believe that if you use public key authentication you're probably immune to man in the middle attacks.

The SSH 'protocol' is actually three pieces: a transport protocol that creates the basic encrypted session, an authentication protocol, and a connection protocol. When a SSH connection starts, the transport protocol negotiates a shared session key and a session identifier and in the process validates the host key of each end. Although I'm not qualified to say if it's fully successful in this, the transport protocol attempts to make sure that the session identifier can't be fully controlled and set by either end; it's always a blend of things from the server and the client.

Once the transport is running, SSH attempts public key authentication in the traditional way: it assembles a known block of data, signs it with the private key, and sends the signature to the server to be verified. Note that the client does not send the block of data, just the signature. This known block of data includes the session identifier. Thus, in order to pass user authentication with the server, you need a signature that uses the session ID of your connection to the server. Unless you know the victim's private key (not just their public key), you need to somehow force the client's connection to you to wind up with the same session ID as your connection to the server so that you can simply relay the client's user authentication message to you on to the server.

I can't categorically say that a man in the middle can't arrange identical session IDs for each connection; I don't know enough cryptography (and understand the SSH protocol that well). However, part of the session ID comes from the public Diffie-Hellman key parameters and my best understanding is that you cannot feasibly recover a D-H key from the public parameters alone. It sure looks like a MITM must do this in order to arrange for identical session IDs; it must present the client's public parameter to the server (instead of its own) and the server's public parameter to the client (instead of its own), yet still wind up with its own valid keys for both connections.

(You can of course trivially impersonate a server (at the SSH level), even without knowing someone's public key. All you have to do is accept whatever signature they send you without even checking it, because the whole user authentication step has no effect on the session encryption; it's only used by the server to decide whether or not to give you access. But this is a lot less dangerous than a genuine MitM attack.)

The many ways PCs can dual boot multiple OSes

In response to yesterday's entry, a commentator asked a question related to dual booting. That means it's time to open the can of complexity that is dual booting on PCs. One of the reasons that dual booting is much more complex than how PCs boot the main OS is that there are at least three different ways that you can boot an alternate OS:

• you can load the other OS's boot sector and jump to it, just as if it was the real MBR being loaded by the BIOS. This is simple and basically guaranteed to work, but it requires that you capture and maintain the boot sector (and the primary partition table that is embedded into it), and the rest of the OS's bootloader has to be on disk where it expects it to be (which may be where your bootloader also wants to go).

  (For obvious reasons this is a favorite technique of boot sector viruses.)

  I believe that GRUB chainloading usually does this. There seems to be more or less a standard where many OSes stick a properly set up copy of their boot sector in the first sector of their BIOS partition.

• you can load and jump to the other OS's bootloader itself (what's often called the second stage bootloader), loading it either from where it normally lives or from a copy that's located in a place more convenient for you. The drawback of this approach is that loading a bootloader second stage and transferring control to it is somewhat more complicated and more bootloader specific.

  (Although since the second stage is loaded by the boot sector and the boot sector code is very small, this is generally not going to be that complex. Still, second stage bootloaders can live in all sorts of places depending on the OS.)

• you can directly load and start the other OS's kernel and any additional bits that it needs. The drawback is that loading a kernel, setting it properly, and passing boot parameters to it is complex and OS dependent (and changes every so often, which means that your bootloader has to keep up). Also, generally you need to understand the OS's filesystem (whatever it is), since kernels are usually in the filesystem (unlike live bootloaders).

  However, if everything works this is the most direct way of booting another OS plus you can do everything in a single step; you do not have the user experience of telling the computer to boot another OS twice (once for the real bootloader and once again to the other OS's bootloader).

Every so often people in the open source world have tried to create a common generic boot protocol for loading OS kernels and passing arguments to them; one example is the GRUB Multiboot protocol. These have the goal of eliminating most of the complexity of the last approach, which is especially important for people who are trying to create a generic open source bootloader since they would rather not maintain special kernel setup code for each different free Unix. My impression is that none of these protocols have really caught on and the major open source OSes like Linux have preferred to stick to their existing kernel setup protocols.

Some of dual booting interacts with partitioning. If you use chainloading from the first sector of an OS's partition, well, your bootloader has to be able to find that; generally this only requires knowing the global partitioning scheme in effect (eg, BIOS primary and extended partitions). If your bootloader is directly loading the OS's kernel it needs to understand enough of the OS's own partitioning scheme (if any) to let it find the filesystem with the kernel. If the OS nests its own partitioning scheme inside BIOS partitioning, your bootloader will need to understand both in addition to being able to read the OS's filesystem.

(Here we can see a subtle win from the Linux decision not to have its own disk partitioning scheme. Since Linux partitioning is BIOS partitioning, Linux bootloaders only have to know one sort of partitioning. Or zero sorts of partitioning in the case of LILO.)

Sidebar: the extremely minimal bootloader

All of this description has assumed a relatively sophisticated bootloader. Bootloaders don't have to be sophisticated; they can be extremely minimal instead. A minimal bootloader does not try to understand and parse anything; not partitioning, not filesystems. Instead it loads things through a hardcoded set of mappings of disk blocks (probably encoded as extents) and the mapping information is maintained outside of the bootloader itself. Such a minimal bootloader is completely agnostic about partitioning and filesystems, although the tool to maintain the mapping data needs to be able to generate the block map for files on the disk.

As you might guess from what I said above, LILO is an example of such a bootloader.