Talk:Dm-crypt/Encrypting an entire system

From ArchWiki
Jump to navigation Jump to search

Merging plain dm-crypt instructions with LUKS instructions

I just noticed that the instructions are fairly similar for encrypting a system with LUKS and without. LUKS is just a header at the beginning of the device or partition that dm-crypt is created on; it doesn't change the device mapper configuration or partition layout in any way. Encryption on LVM and LVM on encryption definitely need separate instructions because they are very different setups, but whether or not LUKS is involved really only affects one command in the entire tutorial:

Without LUKS:

# cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc

With LUKS:

# cryptsetup luksFormat /dev/sdx3

Other than that, the procedure is the same, is it not? We would still need to discuss what LUKS is and whether or not to use it (Dm-crypt/Encrypting_an_entire_system#Setup_encryption should remain, and could be moved to the top of the article, for example), but I don't think we need completely separate instructions for LUKS and plain dm-crypt. In the few cases where the setup procedure does differ, we could make a small note about what to do if using plain dm-crypt). For example, we could add this to the "Preparing the disk" sections:

Note: If you are using plain dm-crypt, it is recommended that you fill the mapped device before continuing. See Dm-crypt/Drive_Preparation#dm-crypt_specific_methods for instructions.

Nearly all the other steps -- including dedicated /boot partition preparation, LVM setup, mkinitcpio hooks, and bootloader installation -- are identical whether LUKS is used or not. In fact, the current layout seems more cumbersome, as Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt currently forks its instructions at certain points based on the decision of LVM on encryption vs encryption on LVM. It seems that it should be the other way around (LVM on encryption / Encryption on LVM sections should fork based on LUKS vs plain, as the latter pair are far more similar to each other.

Notice I imply changing the word "LUKS" to "encryption", as it could imply LUKS or plain dm-crypt interchangeably. Of course, LUKS is still the much more common use case of the two (in fact, the [FAQ] doesn't really recommend plain dm-crypt at all.)

Without looking at the edit history, I would guess the reason they are currently separate is a relic of merging Dm-crypt with LUKS and Plain dm-crypt without LUKS into this page. I don't really have any experience with plain dm-crypt, to be honest, so I could be wrong about this, and I wanted to ask for some other opinions before I go making drastic changes. EscapedNull (talk) 21:19, 10 December 2013 (UTC)

Let's go step by step, don't do too much merging at the same time (also considering our rule to do several little edits instead of a few big ones). First I'd say let's reorganize Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt to make it look as similar as possible to the other scenarios. Then we can assess the possibility of merging it to the LUKS scenario. However note that they don't have the same kernel parameter (boot loader) configuration, as you instead wrote. -- Kynikos (talk) 06:32, 11 December 2013 (UTC)
Sounds good to me User:Kynikos. I just wanted to make note of it and have the possibility considered at some point. As far as the kernel boot parameter, I think you're referring to
which is required with plain dm-crypt, in addition to cryptdevice=. I did forget to mention that, since LUKS stores that information in the header. I'm not saying that the setup procedures for plain dm-crypt and dm-crypt with LUKS are identical, just that they are probably similar enough to be part of the same tutorial, with a few "If you are using plain dm-crypt..." notes here and there. At any rate, we can focus on that after Dm-crypt is figured out, as you suggested. EscapedNull (talk) 15:09, 11 December 2013 (UTC)
+1 to step-by-step. Though, I'd state my opinion right away that merging will make our simple first scenario (intended for the average laptop user with simple partitioning requirements) more complicated than necessary. The plain scenario needs crypto and an usb-key, LUKS not.
Cutting the plain example down to its original example (ie. not the plain defaults) intent should keep it an interesting howto for those who require or want plain attributes (and read down the page). Sidenote: A conditional "if" in the plain dm-crypt scenario could be placed too:
Note: If you have a requirement for a blockdevice without a cryptheader but want to use LUKS instead of plain mode, consider placing the header remote on an usb-key with the --header option.
Just suggesting we might reach both audiences better this way;) --Indigo (talk) 22:18, 11 December 2013 (UTC)
"The plain scenario needs crypto and an usb-key, LUKS not." I'm not exactly sure what you mean. Yes, plain dm-crypt does require cryptsetup options defining the type of crypto, whereas LUKS does not. How does plain dm-crypt require a USB drive in a way that LUKS doesn't? They both need an unencrypted /boot device; that's not dependent on plain versus LUKS. The exact cryptsetup commands will differ depending on plain versus LUKS, but the semantics are the same. We can leave the "simple" scenario alone for the sake of keeping it simple.
I like the --header idea. I didn't realize such an option existed, and it might have some interesting use cases. It's probably worth mentioning. EscapedNull (talk) 23:03, 11 December 2013 (UTC)
I should have wrote plain needs an usb-key more. I was referring to the scenario employing the usb-/boot for a number of security reasons which are more desirable/important if using plain. Nonetheless, the example scenario (with usb keys) still gives a howto for the usb-part which readers can apply to the other scenarios. First scenario simple, then different specialties in the others, stating in the intro that mix&match should be done for the individual case. Makes sense? --Indigo (talk) 21:03, 12 December 2013 (UTC)
I see what you mean. We could probably just link to Dm-crypt/Specialties#Securing_the_unencrypted_boot_partition for that, right? I'm in agreement about mixing and matching individual cases, but does this mean you'd rather keep LUKS and plain separate, or merge them together? EscapedNull (talk) 04:14, 14 December 2013 (UTC)
I'd keep them separate. All of the sections we have on this subpage for one install scenario as simple as possible. --Indigo (talk) 12:37, 14 December 2013 (UTC)
I went astray a bit, but have now worked through the plain scenario and shortened it according to above suggestion. The GRUB installation notes I left in, because of the USB /boot which is desired. Please have a look sometime under the light of above talk. --Indigo (talk) 22:07, 10 February 2014 (UTC)
Well done! I've just fine-tuned it a little bit. However I think the old intro ([1]) has been cut too much, including the "Plain mode pros and cons" section: that information could instead have been useful in the unified overview we discussed in Talk:Dm-crypt#Scenario_intros. -- Kynikos (talk) 14:26, 11 February 2014 (UTC)
Thanks for the tuning. Yes, I was indecisive about the "pros and cons" section and decided to shorten it to verbose for more uniformity. +1 to moving the arguments to a unified overview once that's in place. Possibly some table format could be helpful to keep it short.. Or something simple like
  • Scenario 1
    • (descriptive sentence/usecase)
    • Advantages
      • Ad1
    • Disadvantages
which might get too long(?)..
--Indigo (talk) 21:52, 11 February 2014 (UTC)
A table is cleaner if the content is kept short enough, otherwise a list is better. The table could be something like:
Scenarios Description Advantages Disadvantages
#Scenario 1 Desc 1 Adv 1 Dis 1
#Scenario 2 Desc 2 Adv 2 Dis 2
-- Kynikos (talk) 05:51, 12 February 2014 (UTC)
I started drafting a table to see how it works on my user talk. --Indigo (talk) 21:11, 16 February 2014 (UTC)
I see, what about something simpler like #Table draft? -- Kynikos (talk) 09:50, 17 February 2014 (UTC)
Darn, I did not see below; had the same idea and enthusiastically created a similar second version in the other talk :) Your bullets are smarter though. Let's use this one and finetune content. edit: I'm done with changes. Copy it over, if you are content with it. --Indigo (talk) 12:32, 17 February 2014 (UTC)--Indigo (talk) 11:14, 17 February 2014 (UTC)
Ahah we've indeed had the same idea! Just a curiosity: why do you start the descriptions with a lower-case character? It would look better upper-case to me, just saying...
Anyway, you've written all the content, so you should be the one adding it to the article. I think Dm-crypt/Encrypting_an_Entire_System#Overview is the best place, although there's still Talk:Dm-crypt#Scenario_intros where we concluded that the current overview should be moved to Disk Encryption.
-- Kynikos (talk) 13:20, 18 February 2014 (UTC)
Alright, done. I revisited Disk Encryption first, contemplated about merging the intros EscapedNull added and, contrary to our previous conclusion, think they are right to the point and we should keep them here. In the end Dm-crypt#Common_scenarios jumpstarts dm-crypt. I shortened both slightly in 1 and 2 to sweeten the drop. Started the table descriptions with lower-case, because I phrased them so that the scenario header+verbose gives a meaningful sentence (and left the breaks in because it looks cleaner to me). Can we close this, before it gets longer than the scenario page itself? --Indigo (talk) 20:28, 18 February 2014 (UTC)
Well done! Closed. -- Kynikos (talk) 05:19, 19 February 2014 (UTC)

Table draft

No signatures nor comments in this sub-section.

Scenarios Advantages Disadvantages
#Simple partition layout with LUKS

shows a basic and straight-forward set-up for a fully LUKS encrypted root.

  • Simple partitioning and setup
  • Inflexible; disk-space to be encrypted has to be pre-allocated

achieves partitioning flexiblity by using LVM inside a single LUKS encrypted partition.

  • Simple partitioning with knowledge of LVM
  • Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)
  • Volume layout not transparent when locked
  • LVM adds an additional mapping layer and hook
  • Less useful, if a singular volume should receive a separate key

uses dm-crypt only after the LVM is setup.

  • LVM can be used to have encrypted volumes span multiple disks
  • Easy mix of un-/encrypted volume groups
  • Complex; changing volumes requires changing encryption mappers too
  • Volumes require individual keys
  • LVM layout is transparent when locked
#Plain dm-crypt

uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys.
This scenario also employs USB devices for /boot and key storage, which may be applied to the other scenarios.

  • High care to all encryption parameters is required
  • Single encryption key and no option to change it


A while ago User:Indigo added a reference to the LVM on LUKS on LVM scenario with [2], which was later modified with [3], and finally deleted with [4].

IMO it would be interesting to restore it as a stub section here, like Dm-crypt/Encrypting_an_Entire_System#LUKS_on_software_RAID, waiting for somebody to fill it up, what do you think?

I've also found a forum thread: [5].

-- Kynikos (talk) 14:09, 18 February 2014 (UTC)

It sure is an interesting use case, but I am hesitant. The main reason is that it has to be certain that udev device discovery (be it with encrypt or sd-encrypt) is rock solid longterm for such a setup, see e.g. [6] for related problems. The edits you refer to originate from before that and also before systemd. Therefore I think it would be sensible to have developer input on viability/route for such a sandwich.
I am biased though, I generally prefer encryption as the first mapper. One reason is that it is very easy to seriously wreck a LUKS blockdevice with a single resize statement, if lvm hovers over it.
A final thought on LVM: crypttab offers vanilla flexibility for multiple disks. It would be interesting to know, if someone runs an Arch setup with multiple non-root fully encrypted disks, mounted via crypttab/fstab and joined to a single VG. That might be a worthwhile alternative extension for the shorter Dm-crypt/Encrypting_a_Non-Root_File_System ?
edit: before I forget - a variation of above alternative extension on the non-root page instead may be not to use LVM but have multiple non-root fully encrypted disks and use a btrfs raid1 inside it. Users experiences with that might also be interesting for others.
Plenty of food. Looking forward to read/learn other opinions/experiences. --Indigo (talk) 22:13, 18 February 2014 (UTC)
Thanks for all these interesting observations. Let's keep it on hold then, at least now we have a reminder for this case. -- Kynikos (talk) 05:33, 19 February 2014 (UTC)
Anytime. Good you brought it to the table. --Indigo (talk) 10:51, 19 February 2014 (UTC)