Ah, that makes sense. It clicked with me after reading the paper on the wiki. When you set up the system, it generates a random "master key", which each key slot encrypts separately. So unlocking any key slot unlocks the master key, which is then used to decrypt the disk. That's rather clever actually. At the moment I'm only planning to encrypt the onboard HDD of the laptop, mainly to protect it against unauthorised access. It's a brand-new machine, so I guess there won't be any noticeable latency with an i3 or i5 processor. I had a few concerns as at the moment I'm using a 5+ year old Pentium "D" (P4 with hyperthreading?) and I get noticeable latency with some applications; I didn't want to potentially add to that. What are some potential worst-case scenarios? i.e. the system had a hard reset, either because the power got cut or (somehow) an application brought the system to a complete halt? How would this affect the encryption, and could it result in total data loss? The FAQ makes mention that the most frequent cause of data loss is either losing access to the keys or somehow corrupting the LUKS header. The former I can understand, and "common" sense would dictate to have a couple of backup keys in secure locations. I am at a loss though as to how someone could unintentionally corrupt the header though. I'm inclined to set up my system with /boot and a LUKS partition, and then use LVM inside that, so if I decide to rearrange virtual partitions I won't run the risk of messing up the LUKS header. This also seems like the simplest setup. (I keep daily backups of $HOME and of essential system settings, the rest can be reinstalled if needed, but I'd prefer not to have to spend a few days recovering everything if I had a hard reset or something like that.) Robbie _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
