All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] Encrypting several disks with the same password + keyfile combinaison
@ 2014-04-14 19:24 Xavier MONTILLET
  2014-04-14 22:20 ` Matthias Schniedermeyer
  0 siblings, 1 reply; 3+ messages in thread
From: Xavier MONTILLET @ 2014-04-14 19:24 UTC (permalink / raw)
  To: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]

Hi,

I have a laptop with a SSD (which will contain the root) and a HDD (which
will contain space-consuming things such as /home) and I would like to
encrypt everything it contains with a keyfile and a password. I also have a
non-encrypted USB key that will contain /boot and the initrd. I also would
like to be able to backup the keyfile easily without having to back up
something actually bigger than the keyfile.

After reading the whole FAQ, what I've understood leads me to organize
things as follow:

--- (A) Disk layout ---

- Two unencrypted partitions on the USB key:
  * boot-fs: will be mounted as /boot and contains the initrd
  * key-fs: will contain the keyfile (it is not on boot-fs because there is
no point keeping it mounted after leaving the initrd, and I can always
mount it manually if I need it to change the password protecting the master
password)
- One encrypted partition on the SSD:
  * root-fs: will be mounted at /
- Several encrypted partitions (meaning several LVM partition all sharing
the same encryption):
  * swap-fs
  * var-fs
  * home-fs
  * ...

--- (B) Ensure that both password and keyfile are required ---

(1) The original idea was to encrypt key-fs with the password, hence making
sure that both the password and the USB key are needed to decrypt the other
disks. But I want to be able to easily back up the keyfile (where backing
up means writing it on a paper without the use of a printer). And
encrypting key-fs would mean adding a lot of "useless" bytes around the
keyfile.

(2) Hence the second idea: Since I'll have to play with initrd anyway
(because by default, it doesn't like mounting a system that isn't the new
root first), I could write a script that would prompt me for the password,
concatenate it with the content of the keyfile and use that as key. I
wanted to know whether this looks to you like a terrible idea or not.

(3) I am of course open to a third option but I couldn't find any.

--- (C) Encryption of the actual data ---

(1) About the encryption of the actual data, I have 3 options:
- (a) Use dm-crypt directly and assume the concatenation of a user-typed
password and a keyfile of random bits something can (safely) be used as a
master password (is this true?).
- (b) Use LUKS (which I would prefer to avoid, if it doesn't comprimise the
security, because it adds a weak spot against disk failure: the header)

(2) Then, since I have several partitions, I have to decide between:
- (a) Using decrypt_derived (that would be simpler but the FAQ says that's
not what it's intended for)
- (b) Starting by decrypting a partition containing one keyfile per
remaining encrypted volume (or just one for all of them?). And I again have
the choice of LUKS vs dm-crypt but here, since the keyfile is random, there
must be little difference between the two so I'd go with dm-crypt.

---

Thank you in advance for you answers,

Xavier Montillet

[-- Attachment #2: Type: text/html, Size: 3502 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dm-crypt] Encrypting several disks with the same password + keyfile combinaison
  2014-04-14 19:24 [dm-crypt] Encrypting several disks with the same password + keyfile combinaison Xavier MONTILLET
@ 2014-04-14 22:20 ` Matthias Schniedermeyer
  2014-04-15  9:52   ` Xavier MONTILLET
  0 siblings, 1 reply; 3+ messages in thread
From: Matthias Schniedermeyer @ 2014-04-14 22:20 UTC (permalink / raw)
  To: Xavier MONTILLET; +Cc: dm-crypt

On 14.04.2014 21:24, Xavier MONTILLET wrote:
> Hi,
> 
> - (b) Use LUKS (which I would prefer to avoid, if it doesn't comprimise the
> security, because it adds a weak spot against disk failure: the header)

Interesting point.

There are more "weak spots". Yyou even add one, but i guess adding two 
is "too much"?
- Partition Table
- Superblock(s) of the filesystem(s)
- LVM
- There are or at least i think there are a few "critical" blocks in 
each filesystem that i think will ruin your day if damaged.
- ...

Personally i unintentionaly did away with one (Partition Table) and 
don't use another (LVM), but that still leaves at least the 
superblock(s) of the filesystem.

Btw. You can also use LUKS with a deattached header and/or backup the 
header, so it's not weaker than the other weak spots.




-- 

Matthias

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dm-crypt] Encrypting several disks with the same password + keyfile combinaison
  2014-04-14 22:20 ` Matthias Schniedermeyer
@ 2014-04-15  9:52   ` Xavier MONTILLET
  0 siblings, 0 replies; 3+ messages in thread
From: Xavier MONTILLET @ 2014-04-15  9:52 UTC (permalink / raw)
  To: Matthias Schniedermeyer; +Cc: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Thank you for you answer :-)

Since, as you explained, there is no real drawback to C.1.b and since C.1.a
could cause a problem because the master key isn't random, it looks like
the best way to go is C.1.b.

Then, since the concatenation of the password and the keyfile isn't used as
a master key, it should be safe to use B.2.

So the only question remaining is whether C.2.a is safe.

[-- Attachment #2: Type: text/html, Size: 460 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-04-15  9:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-14 19:24 [dm-crypt] Encrypting several disks with the same password + keyfile combinaison Xavier MONTILLET
2014-04-14 22:20 ` Matthias Schniedermeyer
2014-04-15  9:52   ` Xavier MONTILLET

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.