Talk:Dm-crypt/Device encryption

From ArchWiki
Latest comment: 16 February by Indigo in topic Automatic encryption sector size

Encryption options for LUKS mode example

It is not made clear why section Encryption options for LUKS mode has an example section.

  • Are the defaults not good enough?
    • If the defaults are not good enough, explain the differences.

I find the example use of /dev/random bothersome considering the resources about /dev/urandom vs. /dev/random:

Snassar (talk) 14:15, 22 November 2015 (UTC+1)

I reverted your edit because it removed useful information documenting default options in the table, on what looks to me an insufficient ground.
I agree that wording and presentation of this section could be improved to better separate out the example, and explain its own pitfalls (e.g. uselessness of using random), but bumping the iteration time because you are replacing SHA1 by SHA256 while cryptsetup FAQ specifically address why this is not needed (point 5.20) and removing the explanation about XTS splitting the key size does not improve the section.
Neitsab (talk) 13:46, 22 November 2015 (UTC)Reply[reply]
I made a series of changes culminating in this revision which integrates your remarks and links. I noticed at this occasion that sha256 and --iter-times 2000 were the new compiled-in defaults, so my bad for calling out your use of them.
Tell me whether that looks good to you, so we can close this discussion if it is. Neitsab (talk) 14:54, 22 November 2015 (UTC)Reply[reply]
Thank you for looking back at the edit. Over all it looks good.
I still don't see why an Example column is needed in the table as an example is already stated; the cryptsetup defaults.
I refer back to my questions above. The recommendations here and on other pages go against what current research and knowledge tells us. So it either needs to be addressed or explained or changed. I attempted to change it.
On a separate note, I do not believe what I did qualifies as a radical restructure or rewrite. Samir Nassar - dixi et salvavi animam meam (talk) 17:48, 22 November 2015 (UTC)Reply[reply]
After making those edits I now also wonder what the "hardened" example brings to the section. I think we could remove the whole column while not touching anything else but the table presentation sentence and be better off. However I'd like to have a third opinion on this, so let's give it a few days to hopefully gather somebody's else view before acting.
I didn't say your edit was a "radical restructure or rewrite", but it touched the structure of the table enough that a mere list could replace it and removed useful information about the different options in the comment section, while leaving some leftover cleaning to be done (the sentence introducing the table was still referring to "another set [of options] in the right column"). Agreed, the last point is a minor one (which could have been addressed in a subsequent edit as is the recommended practice).
I made a few new edits to emphasise that using /dev/urandom is (almost) always better, which I believe is the only "recommendation" (note that the example is a mere illustration of alternative options, nowhere it is said to be better) that goes really against best practices. Check the current revision and tell me what you think.
Neitsab (talk) 18:34, 22 November 2015 (UTC)Reply[reply]
For the most part, this works for me. Samir Nassar - dixi et salvavi animam meam (talk) 18:49, 22 November 2015 (UTC)Reply[reply]
I've gone through all the edits and I like them, thank you. I add my support for the removal of the Example columns, as those values do lack a clear justification. Regarding Snassar's original edit, I also agree that it should have been split into smaller edits accompanied with more accurate edit summaries. — Kynikos (talk) 03:39, 23 November 2015 (UTC)Reply[reply]
Indigo just made this edit which more strongly recommends using /dev/random for master key generation; this made me check back cryptsetup FAQ, where I discovered it clearly took position on this topic in item 5.17:
"From the aspect of actual security, LUKS with default parameters should be as good as most things that are FIPS-140-2 certified, although you may want to make sure to use /dev/random (by specifying --use-random on luksFormat) as randomness source for the master key to avoid being potentially insecure in an entropy-starved situation."
I believe cryptsetup authors (or FAQ maintainer at least) can be trusted for their judgement on all things crypto, so it makes sense to keep it as an alternate example... But then how do we get rid of the example column?
What I suggest is to remove the example column altogether but add a warning just after the table, drawing attention to the issue of entropy-starved environments and the added security of using /dev/random. As Indigo wrote in his edit summary, "key generation is [done] once, so really [it] does not hurt much to not compromise.
Does that seems satisfying to you? Neitsab (talk) 23:32, 24 November 2015 (UTC)Reply[reply]
Hi, sorry I did not see this discussion before I made more adjustments yesterday; thanks for opening it Snassar. The intention of my change was exactly how Neitsab summarized it. To add shortly: the links quoted above discuss generally, i.e. mix all sorts of crypto applications (some like SSL require randomness each runtime start, others like blockdevice encryption just once at device setup). If /dev/urandom was considered inadequate, it would indeed not be cryptsetup default for LUKS mode. Still, what should be your default depends on your use-case and system state of your installation machine. For discussion of the topic the linked Random number generation is better suited.
Regarding the elimination of the "Example" column: Three arguments to consider keeping it: 1. The column initially came into existance because a lot of users/wiki editors who care about such crypto details started doing individual edits in good faith here and there, e.g. by adding --hash sha512 --iter-time 3456 --use-random to a luksFormat command somewhere in the content. To avoid such it seemed to make sense to use an example which goes to the maximum crypto a default installation offers. 2. It is intentionally named "Example" and not "Recommended options". As usual with Arch it's up to the user to make an informed choice. 3. It brings synergies, because the plain mode subsection table has the same "Example" column.
Fine with me, if you decide to remove the column after considering above. Personally I would not consider an extra warning template necessary, the "Comment" column has the info/crosslink. Cheers. --Indigo (talk) 10:59, 25 November 2015 (UTC)Reply[reply]
It's great to see you around again, Indigo, thanks for keeping watching these articles as always!
Actually I still think that the "Example" column can be misleading as reported in the OP (and I mean in both tables, which addresses your point 3).
To solve point 1), what if we merged the notable non-default values in the respective comments? IMO, the only values that do need a mention are --use-random in the LUKS table and a --key-file example in the plain table; the rest still seems unnecessary to me.
Regarding point 2), if we want to keep the column, what if we renamed it at least "Most secure" with a Note above or below the tables that briefly explains computational efficiency vs security, maybe with an external link?
Kynikos (talk) 05:44, 26 November 2015 (UTC)Reply[reply]
Hello. Looking back at the time when I was a beginner in cryptography in Linux, this column seemed very strange to me: it seemed to propose better security over the default, so this let me use these values ('cause, why not?).
But actually it wasn't the best thing to do: as we had above, /dev/random is not necessary, increasing the iteration time going against usability (knowing that, crazy that I am, and I hope most security-aware people are, I generally use passphrases of I suppose over 70 bits entropy, and according to the Cryptsetup FAQ 5.1 and 5.10 that's more than enough to have a small iter-time), choosing a higher hash also. So these things should be clearly labelled as possible but not necessary, so that users with yet little technical knowledge are not lent into a time-consuming overkill.
Furthermore, the columns for the cipher and for verify-passphrase are redundant now and do not help readability. So I find this example column not really necessary.
But then again, as in "As usual with Arch it's up to the user to make an informed choice," this information about the possibilities should be kept available. And in that sense, every available choice should be documented. But that would not fit into the page. Maybe there is another page where all options are (or could be) listed exhaustively?
And what about proposing to increase the key-size to 512 in response to XTS to have AES-256, which still makes sense to me? Dinghy (Talk) 01:01, 11 December 2015 (UTC)Reply[reply]
Good points and ideas abound, but I hold myself out of the discussion.
@Kynikos: thanks for the re-welcome. --Indigo (talk) 14:26, 24 December 2015 (UTC)Reply[reply]

Doubt on description

Related to "Default only for luksFormat and luksAddKey. No need to type for Arch Linux with LUKS mode at the moment." description for --verify-passphrase in #Encryption_options_for_LUKS_mode, I find it a bit confusing. Can someone please explain? What does not need to be typed? -- Josephgbr (talk) 01:18, 9 December 2019 (UTC)Reply[reply]

I've just clarified that statement: the "moment" it was added was 2012 with [1] and then [2].
What "does not need to be typed" is the --verify-passphrase option itself, since on Arch's cryptsetup it's clearly enabled by default (just try it), however I haven't really been able to find where exactly we configure that in our package build scripts, so maybe let's keep this open until somebody comes up with a reference.
-- Kynikos (talk) 10:49, 9 December 2019 (UTC)Reply[reply]

Using --perf... options

--perf-submit_from_crypt_cpus and --perf-same_cpu_crypt may improve cryptsetup performance. See https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ for more info. This could be added beside cryptsetup benchmark. Pickfire (talk) 04:37, 9 July 2020 (UTC)Reply[reply]

If you read carefully the linked Cloudflare article, those options actually worsened performance for them (or at least one of the two options did, and the other didn't bring such a great change).
However, since that time their changes have been submitted upstream and then merged in kernel 5.9. They are available since cryptsetup 2.3.4 and can be enabled using the --perf-no_{read,write}_workqueue options in cryptsetup open and refresh operations[3].
I have it in my backlog to add these new developments to the article, however this week people started reporting crashes on Btrfs with high IO load so I am holding off a bit... Note that I have been using them on XFS with low IO load without any issues, and they do show improved throughput as advertised in standard tests, so YMMV. Neitsab (talk) 01:20, 5 December 2020 (UTC)Reply[reply]
Special:diff/652530 added a section to Dm-crypt/Specialties#Disable workqueue for increased solid state drive (SSD) performance later. dm-crypt maintainers turned down making it default recently [4], so indeed YMMV. Closing. --Indigo (talk) 16:25, 16 February 2024 (UTC)Reply[reply]

Bitlocker support

Since Cryptsetup 2.3.0 Release Microsoft Bitlocker is suported: https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.3/v2.3.0-ReleaseNotes

This could be added in the wiki, maybe together with a link to already existing Truecrypt support (https://wiki.archlinux.org/index.php/TrueCrypt).

Ua4000 (talk) 11:59, 3 October 2020 (UTC)Reply[reply]

Go ahead and draft a section if you feel it would add value. You don't need to ask first for something like this, it's a wiki after all :) Graysky (talk) 15:23, 3 October 2020 (UTC)Reply[reply]
I'm unsure about two things: a) were to put this new chapter in the wiki - there are many pages dealing with dm_crypt... maybe this page or maybe /Specialties ? b) Bitlocker support is new, I can't test it since I have no bitlocker device, would be good to hear from someone a positive test scenario in read-only mode before putting it into the wiki. Ua4000 (talk) 09:00, 4 October 2020 (UTC)Reply[reply]
You can start a draft in this talk page, it can be finalized later. -- Lahwaacz (talk) 10:40, 4 October 2020 (UTC)Reply[reply]
proposal, after chaper: === Encryption options for plain mode ===

Encryption options for TrueCrypt

Creating a new TrueCrypt container can be done using truecrypt, for opening and accessing an existing TrueCrypt container cryptsetup is the preferred way,

$ cryptsetup open --type tcrypt <device> <dmname>

TrueCrypt#Accessing_a_TrueCrypt_or_VeraCrypt_container_using_cryptsetup

Encryption options for Bitlocker

Since cryptsetup 2.3.0 Release Microsoft Bitlocker is suported, currently flagged as experimental.

Cryptsetup supports Bitlocker activation through passphrase or recovery passphrase for existing devices (BitLocker and Bitlocker to Go). Activation through TPM, SmartCard, or any other key protector is not supported. Read-write mode is supported. Cryptsetup command supports the new "bitlk" format and implement dump, open, status, and close actions. To activate a Bitlocker device, use

$ cryptsetup open --type bitlk <device> <dmname>

or

$ cryptsetup bitlkOpen <device> <dmname>

Since Bitlocker is mainly used at Microsoft Windows, expect to mount a NTFS-3G, VFAT or exFAT file system.

Ua4000 (talk) 12:15, 10 October 2020 (UTC)Reply[reply]

Automatic encryption sector size

According to this Phoronix article, cryptsetup now supports automatically setting the sector size. Indeed it looks like the feature has been merged

Maybe the section about sector size should be updated ?

Cvlc (talk) 16:59, 27 June 2021 (UTC)Reply[reply]

Updated, re Special:diff/707053. Closing. --Indigo (talk) 16:31, 16 February 2024 (UTC)Reply[reply]