From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPf26ROwFdIw for ; Tue, 20 Sep 2011 12:52:57 +0200 (CEST) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 20 Sep 2011 12:52:57 +0200 (CEST) Message-ID: <4E78708A.7090608@laposte.net> Date: Tue, 20 Sep 2011 12:52:58 +0200 From: Quentin Lefebvre MIME-Version: 1.0 References: <1316515022.7965.31.camel@zarniwoop> In-Reply-To: <1316515022.7965.31.camel@zarniwoop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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