From ArchWiki
Jump to navigation Jump to search

New idea

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:

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.

-- Kynikos (talk) 03:08, 23 November 2013 (UTC)

EDIT: since Plain dm-crypt without LUKS would be merged here, the main article should be just renamed to dm-crypt. -- Kynikos (talk) 03:09, 23 November 2013 (UTC)

EDIT: updated for current structure. -- Kynikos (talk) 04:31, 8 December 2013 (UTC)

Scenario structure

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)

Known issues

[Moved from dm-crypt -- Kynikos (talk) 15:40, 8 August 2019 (UTC)]

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: The claim that it takes 2 seconds is unsourced. The delay is specific to LUKS and should differ between LUKS1 and LUKS2. See section 3.4 in cryptsetup FAQ and Cryptsetup 2.0.0 Release Notes. (Discuss in Talk:Dm-crypt#)

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)