On 20/09/2011 12:36, Robbie Smith wrote : > 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. You guess right. > 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? I've never had any trouble with hard reset or so on, as this is typically handled by the file-system checks. Encryption is really transparent. > 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. The FAQ is right here. I actually lost data, each time it was a stupid mistake, like : -> bad 'cryptsetup' invocation, removing (and deleting) a volume -> bad 'dd' invocation, writing on the LUKS header. Indeed, corrupting the LUKS header seems to be the only potential problem, and you do have to make a mistake to do this (or be unlucky enough). AFAIK you can backup the LUKS header, with the security concerns it can raise. > 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. This look like a nice design. Best, Quentin _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
