DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Lefebvre <alto.spam@laposte.net>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM
Date: Tue, 20 Sep 2011 12:52:58 +0200	[thread overview]
Message-ID: <4E78708A.7090608@laposte.net> (raw)
In-Reply-To: <1316515022.7965.31.camel@zarniwoop>

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

  reply	other threads:[~2011-09-20 10:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20 10:36 [dm-crypt] (More) Questions about LUKS / LVM Robbie Smith
2011-09-20 10:52 ` Quentin Lefebvre [this message]
2011-09-20 11:47 ` Arno Wagner
2011-09-20 13:13   ` Milan Broz
2011-09-20 14:14     ` Arno Wagner
2011-09-20 14:52       ` Milan Broz
2011-10-03  6:17       ` Luca Berra
2011-10-03 10:55         ` Arno Wagner
2011-09-20 15:21   ` Alexander Koch
2011-09-20 16:12     ` Milan Broz
2011-09-20 17:41     ` Arno Wagner
2011-09-20 18:06       ` Karl O. Pinc
2011-09-20 18:19         ` Milan Broz
2011-09-21 10:22           ` Arno Wagner
2011-09-21 16:14             ` Dragan Milivojevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E78708A.7090608@laposte.net \
    --to=alto.spam@laposte.net \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox