The philosophy behind the
current old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in Dm-crypt with LUKS/draft, so it's used use the dm-crypt#Common scenarios section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:
- dm-crypt/Encrypting a Non-Root File System
- dm-crypt/Encrypting an Entire System
Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of
Dm-crypt with LUKS dm-crypt, pointing out all the particular suggested adaptations that apply to that particular scenario.
The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.
- Plenty of stuff to do, yet: Taking for granted we want an additional example with RAID sometime, it might be worth considering to split dm-crypt/Encrypting an Entire System into a subpage for (e.g.) dm-crypt/Encrypting a single disk system and dm-crypt/Encrypting a system across multiple disks scenarios. The latter covering "LUKS on LVM" and said RAID. Main reason: page length. If you agree, let's better do it now. --Indigo (talk) 12:11, 8 December 2013 (UTC)
- Not a bad idea at all! However IMHO the proposed titles are a bit misleading: I would go for dm-crypt/Encrypting a System on Physical Devices and dm-crypt/Encrypting a System on Virtual Devices, in fact you can use multiple physical disks in every case if you want. -- Kynikos (talk) 03:48, 9 December 2013 (UTC)
- EDIT: Note that the history of dm-crypt/Encrypting an Entire System should be preserved by moving it to one of the two titles, and then (or before) splitting the other page. -- Kynikos (talk) 03:49, 9 December 2013 (UTC)
- +1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --Indigo (talk) 23:16, 9 December 2013 (UTC)
Dm-crypt adds a 2 second (~1.970s) delay when attempting to decrypt, this is to discourage brute force attacks. This adds a significant delay when used autonomously or when monitoring boot time.
- Certainly this is not an "issue", but an essential security feature (key derivation or strengthening), and describing it like a simple added delay is also misleading.
- Anyway if anything, LUKS' key strenghtening mechanism (and its possible practical disadvantages in specific scenarios) should be mentioned in Dm-crypt/Device encryption, not in this overview page.
- -- Kynikos (talk) 15:49, 8 August 2019 (UTC)
Adding info about Adiantum + dm-crypt/LUKS intro
My first idea was to put it in Dm-crypt/Device_encryption since this is where I would go for practical instructions on using different ciphers etc., but after a quick glance it didn't seem to fit well since it would serve as an intro to the "adiantum" term on the wiki.
After looking around I started adding it to Data-at-rest_encryption#Ciphers_and_modes_of_operation, only to realize this section was about "predominantly used [ciphers]", which Adiantum certainly isn't.
This made me realize that the new/current layout, which jumps straight to encryption scenarios, is lacking an intro or "common knowledge" section which would cover cryptography basics like ciphers and such (as the Expansion template points to at the top).
Data-at-rest_encryption seems to fit the bill and is already the redirection target of several generic pages such as Encryption and Disk encryption, so I suggest we add it a bit more prominently to the beginning of Dm-crypt: indeed it seems to be the more prominent portal through which one is led to encryption topics on the Arch wiki and from other web searches.
I know that it already features a link to Data-at-rest_encryption in the Related articles box, but cognitively speaking this is the kind of aside elements that tends to be ignored as it is not directly in the reading flow of the article, while an inline Note template is. It could be as simple as replacing the current Expansion template at the top with the following:
What's the opinion of interested people on the matter? I can go ahead and implement it in a few days if some other wiki maintainer/administrator/trusted users agree.
- Interesting, if you're going to write specifically about the integration with cryptsetup, then Dm-crypt/Device_encryption would be the most suitable place.
- If you want to introduce the cipher in general, then I agree Data-at-rest_encryption#Ciphers_and_modes_of_operation is better, perhaps you can alter its scope to also include less common ciphers.
- I've moved the scenario links in this intro page after the links to the other subpages; I've also removed the Expansion flag. Personally I don't feel like I tend to ignore the Related articles, but I'm not going to object if you want to highlight a link to Encryption in the article body, just perhaps I think wrapping it in a Note template would be a bit too much.
- -- Kynikos (talk) 06:17, 9 January 2021 (UTC)
Regarding section "Configuring the boot loader"
It should be clear that `cryptdevice=` boot parameter is not necessarily used with all bootloaders, e.g. booster uses `rd.luks.name=` and e.g. `rd.luks.options=discard`.
Make note: "`cryptdevice=` or equivalent depending on initramfs generator..."