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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.