Difference between revisions of "Talk:Dm-crypt"

From ArchWiki
Jump to: navigation, search
(Encrypting a LVM setup (section 8): re)
(closing discussions,as suggested, for they've been clarified for me)
(28 intermediate revisions by 6 users not shown)
Line 1: Line 1:
== Cleanup and Clarification ==
+
==<s>Moving the LVM solution to the top</s>==
 
Hello. This wiki page while very exhaustive in content is tangenital with a fractured flow. It seems the prefered method for straight forward system encryption in single drive systems is to use a combination of Luks and LVM2 - this solution provides for an encrypted swap that does not have any issues with hibernation or suspend. I propose making this section the first part of the wiki page to follow the justification for using Luks with the rather large volume of detailed information to follow in other sections. If there are no objections I'll go ahead and structure this in the wiki page itself.
 
Hello. This wiki page while very exhaustive in content is tangenital with a fractured flow. It seems the prefered method for straight forward system encryption in single drive systems is to use a combination of Luks and LVM2 - this solution provides for an encrypted swap that does not have any issues with hibernation or suspend. I propose making this section the first part of the wiki page to follow the justification for using Luks with the rather large volume of detailed information to follow in other sections. If there are no objections I'll go ahead and structure this in the wiki page itself.
 
[[User:Vinhsynd|Vinhsynd]] 9:55, 30 September 2010 (CDT)
 
[[User:Vinhsynd|Vinhsynd]] 9:55, 30 September 2010 (CDT)
  
 +
==<s>Cleanup</s>==
 
Hey all, I was trying to encrypt my hd using this page as a reference, but it was a bit difficult to read. As such, I'm going to try to clean things up a bit. It would be nice if there were a clean set of instructions with tips along the way for specialized setups.
 
Hey all, I was trying to encrypt my hd using this page as a reference, but it was a bit difficult to read. As such, I'm going to try to clean things up a bit. It would be nice if there were a clean set of instructions with tips along the way for specialized setups.
  
Line 8: Line 9:
 
--[[User:Arcanazar|Arcanazar]] 13:22, 21 August 2010 (EDT)
 
--[[User:Arcanazar|Arcanazar]] 13:22, 21 August 2010 (EDT)
  
 +
== Cleanup and Clarification ==
 
I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?
 
I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?
  
Line 69: Line 71:
 
That's all, reboot and have fun! And look if your partitions still work after that ;-).
 
That's all, reboot and have fun! And look if your partitions still work after that ;-).
  
== LVM2 and LUKS ==
+
---
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device.
+
: I removed the section referenced above today with [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&diff=273959&oldid=273945 this] edit. The method described of storing a key was in the past maybe more often used than today. However, it was always dangerous for the partition table and the secrets. There are plenty better options. If someone sees reasons to keep this (and maybe also why we should re-add it to the wiki), please give some input here in talk. Otherwise I'll propose to close this discussion and the related one below sometime later. Thanks. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:24, 1 September 2013 (UTC)
 
+
And you have to add the "encrypt" hook ''before'' the "lvm2" hook, because you need to make the decrypted device available before LVM2 imports volume groupe and makes logical volumes available.
+
 
+
Yet this chapter tends to tell the other way round. Is my English so bad ?
+
 
+
I agree.. I find this entire wiki article unnecessarily complicated .. this link for an LVM on top of an encrypted partition is MUCH!!! easier to follow, and for a laptop would be better. [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]
+
 
+
- This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system.
+
 
+
-- I also agree that the section needs a further overhaul, assuming here everyone commenting means the "Encrypting and LVM Setup" (because "LVM2 and LUKS" is not in the TOC). Having encrypt over (i.e. before) LVM is def the typical and easiest setup (and this should be expanded on more clearly in the wiki like in the link above I agree). However, all methods have a usecase. It depends what the user wants to achieve. Time permitting, the differences should be worked out. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:53, 18 September 2012 (UTC)
+
 
+
==  <s> Prepare hard drive </s> ==
+
The actual text is:
+
 
+
Skip the Partitioning and Auto-Prepare business and go straight to "Set Filesystem Mountpoints". When asked for your {{ic|/}} (root) partition, do NOT select {{ic|/dev/sda3}} as you normally would. Select {{ic|/dev/mapper/root}} instead. Similarly, use {{ic|/dev/mapper/home}} instead of {{ic|/dev/sda4}} as the partition to be mounted as {{ic|/home}}. The same is valid for a swap partition which is set up like the home partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition or else the installer will not properly set up the bootloader.
+
 
+
but the Arch Linux installer says:
+
[code]
+
/dev/sda1
+
/dev/sda2
+
/dev/mapper/root
+
/dev/mapper/lvm-home
+
/dev/mapper/lvm-root
+
/dev/mapper/lvm-swap
+
/dev/mapper/lvm-tmp
+
[/code]
+
When asked for {{ic|/}} (root) partition: is it {{ic|/dev/mapper/root}} or {{ic|/dev/mapper/lvm-root}}. I suppose it is the first one because the second one does not match.
+
  
 
== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition ==
 
== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition ==
Line 124: Line 99:
 
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)
 
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)
  
== systemd addidtions ==
 
systemd requires lvm-on-cryptdevice.service active in order to open LVMs on cryptdevices that are not the root partition (which is handled by the initrd).
 
 
== after 2012.07.15 ==
 
 
What change with the new installation process and systemd change ? If I understand correctly parts related to /etc/rc.conf files are no longer useful but what's the correct way now ? thanks --[[User:Martvefun|Martvefun]] ([[User talk:Martvefun|talk]]) 00:27, 9 January 2013 (UTC) -> question and response asked[https://bbs.archlinux.org/viewtopic.php?id=155863|here]
 
:For reference - two more bbs threads covering the subject: [https://bbs.archlinux.org/viewtopic.php?pid=1212076#p1212076| with systemd] and [https://bbs.archlinux.org/viewtopic.php?pid=1170012#p1170012| with a nice backup script]--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:07, 9 January 2013 (UTC)
 
 
== Encrypted swap With suspend-to-disk support ==
 
Shouldn't the openswap hook go after the encrypt hook? Otherwise you have to always open the root device prior to the swap, even on resume.
 
:You meant to write ".. the openswap go before encrypt ..?" which sounds like a reasonable suggestion. Have you tried it? (I have not). Maybe it works still (without manual unlocking of root) because of the kernel parameter resume=.. In Debian it would go after, but there the key for swap is derived by the hook from the root master key (hence not input extra for swap, which is elegant).--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 6 February 2013 (UTC)
 
 
== Feature of Grub2 to decrypt /boot ==
 
== Feature of Grub2 to decrypt /boot ==
 
Original comment by Chehri on 8.6.13, moved from [Dm-crypt_with_LUKS#Creating_Disk_Partitions] to here:  
 
Original comment by Chehri on 8.6.13, moved from [Dm-crypt_with_LUKS#Creating_Disk_Partitions] to here:  
Line 144: Line 108:
 
:I think the best way forward for the contribution would be to draft a subsection under 3.2 (e.g. as 3.2.7), we have different hook modifications there for the swap. (later on there is a specific section on encrypted keyfiles too where it might fit well). Once the section is complete and accurate to modify a standard Arch, one could link to it from the general section above. Once something like that goes into the vanilla Arch-encrypt hook, it should definetely be described earlier. Another (different) point would be to discuss the pros/cons security-wise of such a modification a bit. That could be done in the subsection too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:35, 8 June 2013 (UTC)
 
:I think the best way forward for the contribution would be to draft a subsection under 3.2 (e.g. as 3.2.7), we have different hook modifications there for the swap. (later on there is a specific section on encrypted keyfiles too where it might fit well). Once the section is complete and accurate to modify a standard Arch, one could link to it from the general section above. Once something like that goes into the vanilla Arch-encrypt hook, it should definetely be described earlier. Another (different) point would be to discuss the pros/cons security-wise of such a modification a bit. That could be done in the subsection too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:35, 8 June 2013 (UTC)
  
== <s>AIF</s> ==
+
==<s>Encrypting a LVM setup (ex section 8) </s>==
 
+
I just came here to try to update information concerning mkinitcpio.conf for LVM-on-LUKS. I'm not sure I've found everything to update as there seem to be several pages which cover similar but not quite the same information.
+
 
+
I was wondering, though, what was planned for the AIF section. I think the inclusion of this is unnecessarily confusing to new users since this has been deprecated for quite some time.
+
 
+
--[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 00:07, 15 July 2013 (UTC)
+
 
+
:Agree it should be deleted.
+
:[[User:Jasonwryan|jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:14, 15 July 2013 (UTC)
+
 
+
::This article has lots of very interesting content, but yeah some parts are outdated just like that one: AIF is dead/suspended (don't remember the official status), that section can go. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:16, 16 July 2013 (UTC)
+
:::Thanks for bringing it up, I removed it (you can find it on my user-page for ~ a month). Next needing clean-up is 8.1 - 8.4 (please state your opinion below, thanks!). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:16, 16 July 2013 (UTC)
+
 
+
==Encrypting a LVM setup (section 8)==
+
 
The content in sections 8.1 to 8.4 has to be updated, particularly the AIF and /etc/rc.conf references must go. Since another user created a "Encrypted LVM" stub article, which (arguably) has style problems but is a good read otherwise, I see two alternatives for section 8:  
 
The content in sections 8.1 to 8.4 has to be updated, particularly the AIF and /etc/rc.conf references must go. Since another user created a "Encrypted LVM" stub article, which (arguably) has style problems but is a good read otherwise, I see two alternatives for section 8:  
  
Line 175: Line 125:
 
::::Thanks for taking the time to check it! Currently I would leave it at A as opposed to C, for two reasons: Firstly, the [[Encrypted LVM]] works/reads well with the two main setup options shown. Then it picks up different important subjects (gpt, multiple disks) but lacks some of the setup the LVM example this page has (e.g. nowhere on [[Encrypted LVM]] you find the word "swap"). So a merge would entail rework of the page in order not to loose content in the merge. Or even adding another example there (better not imho). Secondly, the other installation instructions on this page [[LUKS#Encrypting_a_system_partition]] are deliberately describing the simplest encrypted setup. So, the LVM install example here adds options which a reader might want to mix in (e.g. swap, separate /home; maybe those options are worth a mention revisiting it). I think about it again, but currently I would consider the current split easier comprehensible for both pages and outweighing the duplicity (of LVM commands). Any further LVM install tricks should of course be on the other pages, LUKS tricks here. Thoughts? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:06, 21 July 2013 (UTC)
 
::::Thanks for taking the time to check it! Currently I would leave it at A as opposed to C, for two reasons: Firstly, the [[Encrypted LVM]] works/reads well with the two main setup options shown. Then it picks up different important subjects (gpt, multiple disks) but lacks some of the setup the LVM example this page has (e.g. nowhere on [[Encrypted LVM]] you find the word "swap"). So a merge would entail rework of the page in order not to loose content in the merge. Or even adding another example there (better not imho). Secondly, the other installation instructions on this page [[LUKS#Encrypting_a_system_partition]] are deliberately describing the simplest encrypted setup. So, the LVM install example here adds options which a reader might want to mix in (e.g. swap, separate /home; maybe those options are worth a mention revisiting it). I think about it again, but currently I would consider the current split easier comprehensible for both pages and outweighing the duplicity (of LVM commands). Any further LVM install tricks should of course be on the other pages, LUKS tricks here. Thoughts? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:06, 21 July 2013 (UTC)
 
:::::All right, you convinced me, let's leave it there, thanks again ^^ (this discussion will stay open until all the remaining points are implemented) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:06, 22 July 2013 (UTC)
 
:::::All right, you convinced me, let's leave it there, thanks again ^^ (this discussion will stay open until all the remaining points are implemented) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:06, 22 July 2013 (UTC)
 +
::::::Okies, I added three (sublime:p) link-backs in the [[Encrypted LVM]] howto where I would consider LUKS pointers useful at the least. I will surely revisit the page, but at current A(4) is done from my view. Maybe the merge tag can go for now. Next bits of re-work here on the page may be further streamlining the starting section with better guidance through the page, but that's out-of-bounds this discussion (more the first point on this page). I also marked some old discussions here as closed. It would be nice if you or someone else could look at them sometime and rm as appropriate. Thanks. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:04, 25 July 2013 (UTC)
 +
:::::::Well done, you can remove the merge template and close this discussion then (don't worry, all closed discussions ''are'' removed sooner or later). If you will want to discuss more changes to this article, do not hesitate to open another thread. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:51, 27 July 2013 (UTC)
 +
 +
==Merge with "plain dm-crypt without LUKS"==
 +
[[User:Develper|Develper]] has written a new A-Z howto for setting up a plain dm-crypt system, a subject not covered yet in our wiki. It is discussed how to effectively use common content for the benefit of the articles on disk crypto. If you have ideas or thoughts about it, head over: [[Talk:Plain_dm-crypt_without_LUKS#Merge]]
 +
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:37, 26 August 2013 (UTC)
 +
 +
== Splitting sections into separate pages ==
 +
 +
Does anyone else feel that 11,305 words is too long for a single article? I'd like to propose splitting this article across multiple pages. If MediaWiki's Subpages feature is enabled, this might be a good time to use it. The article contains many sections that are not greatly related to one another. For example, does one really need to know how to (section 6) encrypt a loopback filesystem or (section 3.2) use a keyfile in order to (section 3.3) encrypt a swap partition? It's common to encrypt a swap partition without using a keyfile or an encrypted loopback filesystem, so why are they discussed in the same article?
 +
 +
I acknowledge that all the sections are related to LUKS, but many of them are not dependent on each other. Having many vaguely related topics makes the article difficult to follow and maintain. I propose Subpages because subpages can show their relationship to LUKS (and other sections, just as an example: /LUKS/Configuration/Keyfiles). In the absence of Subpages, placing a general overview of LUKS in the main article -- and links to pages on more specific topics -- would also be an improvement. Separating sections into (sub)pages would also keep talk pages attuned to a specific subject.
 +
 +
I have some suggestions for improvement of individual sections as well, but I think separating sections would be a good first step. [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 14:26, 29 September 2013 (UTC)
 +
 +
:Hi, the article ''is'' among [[Special:LongPages|the longest]], splitting it into subpages could help not feeling overwhelmed by it, however a lot of care should be taken in doing it, that's why I think you've been very wise to start a discussion first. We've had a number of users working hard on it, in particular I'd like to point you to a recent discussion I had with [[User:Indigo]], [[#Encrypting_a_LVM_setup_.28ex_section_8.29]], on which we agreed on keeping [[Dm-crypt_with_LUKS#Encrypting_a_LVM_setup]] here instead of merging it to [[Encrypted LVM]]: moving it to a subpage would somehow conflict with that decision, so I'll try to invite [[User:Indigo|Indigo]] to discuss here with us on what to do now.
 +
:Finally, just to answer your doubts, this wiki doesn't have the subpage feature enabled on the Main namespace, nonetheless subpages (i.e. article names with slashes) are already commonly used to keep series of related articles together, so that would indeed be the way to split this article.
 +
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:54, 30 September 2013 (UTC)
 +
 +
::After reading the discussion, I see what you mean. However, I don't think splitting up the article would interfere too much with the decision to keep a brief overview of LUKS and LVM in addition to the Encrypted LVM page. The setup I had in mind was roughly giving each top-level section its own page (but don't quote me on that). The overview and the Encrypted LVM page seem to overlap, and I don't see much benefit to maintaining both, although [[User:Kynikos|Kynokos]] and [[User:Indigo|Indigo]] might not agree and that's fine. Personally I find the [[Encrypted LVM]] page easier to follow and I think it gives the reader a better understanding of the subject, which is why my own edits on the subject have gone there rather than this page. Case and point, I'd propose replacing the overview with Encrypted LVM (as a pseudo-subpage, or just a link), but maintaining the overview is also okay, and perhaps it would just get its own article or pseudo-subpage. The main point I was trying to make is that I think LUKS/dm-crypt is too broad a topic for a single article. And as you said, I'd also be interested in hearing what Indigo has to say about this. [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 17:24, 30 September 2013 (UTC)
 +
:::Hi, thanks for sharing your ideas here. Getting rid of not required content would be a preferable way, if you ask me. Particularly by (a) streamlining to LUKS and vacuuming for clarity. Then (b) splitting content by moving out sections to new pages can help and be a way forward. Yet I don't see a reason why (a) cannot be done while possibilites for (b) are figured out. If you look at the sections you quote in your first post, you will notice 2/3 have short introductory paras and would work as a subpage or even separate pages. Quite a number of edits were made to that respect and continuing with it should make it easier to re-structure the article, if that is the outcome of the discussion. If not, it is still more readable this way.
 +
:::I don't grasp what you have in mind with replacing the "overview" (?) with [[Encrypted_LVM]]. I would rather merge [[LUKS#LVM:_Logical_Volume_Manager]] (the "overview"?) to there and link it from here. If you are instead referring to [[LUKS#Encrypting_a_LVM_setup]] (and hence the talk quoted by [[User:Kynikos|Kynikos]] above) as the "overview", it would be a great contribution to merge it into [[Encrypted_LVM]]. I am sure [[User:Kynikos|Kynikos]] will agree - he proposed to do that originally. In case you would like to approach the merge, please go forward with it. I'll make sure [[LUKS#Encrypting_a_system_partition]] regains the cross-linked content.
 +
 +
:::Back to your original topic:
 +
:::For (a) maybe you want to re-consider to join in for editing in the suggestions you have in mind first. 
 +
:::For (b) another point that should be addressed along is how the new pages (plain dm-crypt and encrypted LVM) could benefit at the same time. If you ask me now, separating common content would be a preferable approach to using a subpage structure (e.g. like the multipage BG). Perhaps you can detail options you see for (b). How would you re-structure the top sections on this page? Which sections would you fork out from LUKS, ideally with perspective to the other encryption pages? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 05:03, 1 October 2013 (UTC)
 +
::::By "overview" I was talking about section 7 "Encrypting an LVM setup." I didn't even notice that LVM was discussed twice (a testament to disorganization of the page as it is now). I see what you mean about the disadvantages of subpages. I mentioned subpages because, for example, an LVM can be encrypted using almost any block level encryption, and one could argue that setups using different underlying technologies should be separate pages (e.g. LUKS/Encrypted_LVM, Plain_dm-crypt/Encrypted_LVM, and cryptoloop/Encrypted_LVM) as the information is likely to be different (but this could lead to duplicated information, too). It was only an idea, and perhaps something like [[:Category:Disk_Encryption]] would be more appropriate. After all, subpages are disabled for a reason.
 +
::::I thought it would be a good idea to split the article first and edit second because it would be easier to focus on a single topic, and because it could save us from editing information twice in case it conflicts with the new structure. But if you think it would be best to edit first and restructure later, I'm fine with that I guess. Kynikos, do you have a preference? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 13:44, 1 October 2013 (UTC)
 +
 +
==<s>Confusing sentence</s>==
 +
Hi, this sentence "This should be repeated for all partitions except for /boot and possibly swap." is unclear to me; my noobish guess is that it means: "This should be repeated for all partitions and possibly swap, except for /boot" but I am unsure because it appears to mean "except /boot and possibly swap" but I imagine you wouldn't want swap to be unencrypted... Hmm, the more I think about it, it seems both variants seem equivalent though. [[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 01:40, 30 September 2013 (UTC)
 +
 +
:Hi, that sentence means that you can't encrypt a boot partition (well, unless you have [[Wikipedia:Hardware-based full disk encryption|special hardware]]) and that you can or cannot encrypt a swap partition depending on how you're going to encrypt your system. Since it seems you are a bit confused on the topic, I suggest you go with the LVM-on-LUKS solution, which will let you encrypt your swap partition and use hibernation and suspension, see [[Dm-crypt_with_LUKS#Encrypting_a_LVM_setup]] and [[Encrypted LVM]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:19, 30 September 2013 (UTC)
 +
 +
::Thank you, much appreciated. I'll keep reading, I need to understand more before I go through with any of these. -- [[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 03:26, 30 September 2013 (UTC)
 +
 +
==<s>Dual meaning sentence</s>==
 +
In this sentence: "Symlinks can be used in the bootloaders "cryptkey" kernel option or anywhere else." Is there a missing comma or apostrophe at the end of the word "bootloaders", or is it "bootloader's" ? Thanks. -- [[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 14:22, 30 September 2013 (UTC)
 +
:I think "Symlinks can be used in the bootloader's "cryptkey" kernel option or anywhere else." is what was meant. I doubt ''bootloaders'' was meant to be plural, because normally only one bootloader is used on a system. If it were a comma, there would most likely be an article before ''"cryptkey" kernel option'' and a comma after ''option''. My interpretation of the sentence is that paths referring to symlinks within the "cryptkey" kernel option of the bootloader configuration will resolve to the file the symlink points to. That's just my two cents; the only way to be sure is to ask the author. [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 17:40, 30 September 2013 (UTC)
 +
::I'm not the original author, but it is a missing apostrophe as you both guessed. I corrected it: [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&diff=277196&oldid=275544]. [[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) thanks for pointing it out. If you have more questions or see ambigious wording, please state them here anytime. But please remember to close the discussion point after it has been clarified for you. Closing involves just <s>striking out</s> the heading. Closed discussions will stay for a while they get removed automagically. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:50, 1 October 2013 (UTC)
 +
::Thank you all. Striking as suggested :) -- [[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 23:35, 1 October 2013 (UTC)

Revision as of 23:35, 1 October 2013

Moving the LVM solution to the top

Hello. This wiki page while very exhaustive in content is tangenital with a fractured flow. It seems the prefered method for straight forward system encryption in single drive systems is to use a combination of Luks and LVM2 - this solution provides for an encrypted swap that does not have any issues with hibernation or suspend. I propose making this section the first part of the wiki page to follow the justification for using Luks with the rather large volume of detailed information to follow in other sections. If there are no objections I'll go ahead and structure this in the wiki page itself. Vinhsynd 9:55, 30 September 2010 (CDT)

Cleanup

Hey all, I was trying to encrypt my hd using this page as a reference, but it was a bit difficult to read. As such, I'm going to try to clean things up a bit. It would be nice if there were a clean set of instructions with tips along the way for specialized setups.

On a related note... would anyone mind if some of the posts on this page were erased? There are a number of posts from 2007, 2008... --Arcanazar 13:22, 21 August 2010 (EDT)

Cleanup and Clarification

I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?

Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit? WhiteMagic 12:56, 24 May 2007 (EDT)

Clean up is really needed. Please someone with enough knowledge start the job. -- Fengchao (talk) 02:55, 8 June 2012 (UTC)
This is new territory for me, but I want to implement this topic myself soon. I'll start with removing some duplicated content. T1nk3r3r (talk) 07:25, 16 June 2013 (UTC)

Luks and suspend2

Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does:

resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap

I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation.

Proposed update of the section 'Storing the key between MBR and 1st partition'

Background

I tried to setup automatic mount of my LUKS encrypted /home using a keyfile stored between MBR and first partition header of my USB key following this wiki page and realized that it didn't work out because the howto is incomplete. I had to manually go through the encrypt hook to figure out what it does. To save other users this tiresome work that cost me hours until all finally worked out the way I wanted it I propose to update the mentioned section in the following way. Suggestions welcome. Maybe it should be noted in the parent section that /etc/crypttab conflicts with using the howto presented here.

Add the temporary keyfile we created before with cryptsetup:

cryptsetup luksAddKey /dev/hda3 secretkey

That should return you output like this:

Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.

Next you'll have to write the key directly between MBR and first partition.

WARNING: you should only follow this step if you know what you are doing - it can cause data loss and damage your partitions or MBR on the stick!

If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key.

Optional

dd if=/dev/usbstick of=64sectors bs=512 count=64   # gives you copy of your first 64 sectors
hexcurse 64sectors                                 # determine free space

Write your key to the disk:

dd if=secretkey of=/dev/usbstick bs=512 seek=4

If everything went fine you can now overwrite and delete your temporary secretkey:

shred --remove --zero secretkey

You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.

Now you have to add a kernel parameter in your /boot/grub/menu.lst (GRUB), it should look something like this:

kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048 cryptdevice=/dev/hda4:home

Format for the cryptkey option:

cryptkey=BLOCKDEVICE:OFFSET:SIZE

OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be (if you use skip=16 in the 'dd' command above to protect the bootloader)

kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048 cryptdevice=/dev/hda4:home

Format for the cryptdevice option:

cryptdevice=BLOCKDEVICE:MAPPING_TARGET

The encrypted block device BLOCKDEVICE will then be mapped to /dev/mapper/MAPPING_TARGET

Note: You will _not_ need to have /etc/crypttab setup for this device then (but maybe you want to use it for other encrypted devices where you want to enter the passphrase manually or e.g. use a keyfile stored on this afterwards decrypted partition)! But don't forget to activate the encrypt hook in /etc/mkinitcpio.conf (_before_ the filesystems hook)

That's all, reboot and have fun! And look if your partitions still work after that ;-).

---

I removed the section referenced above today with this edit. The method described of storing a key was in the past maybe more often used than today. However, it was always dangerous for the partition table and the secrets. There are plenty better options. If someone sees reasons to keep this (and maybe also why we should re-add it to the wiki), please give some input here in talk. Otherwise I'll propose to close this discussion and the related one below sometime later. Thanks. --Indigo (talk) 19:24, 1 September 2013 (UTC)

Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition

The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition.

System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition makes references to /dev/usbkey but the previous instructions aren't entirely clear on how to ensure your usb drive can always be found at this location.

When modifying your bootloader you will be unable to use /dev/disk/by-uuid because you are not referencing a filesystem. You wouldn't want to use /dev/sd[x] because this can and will change depending on what other drives and media you have connected during boot. The best bet is to create a udev rule that will exist in early userspace to alias your usb drive to an arbitrary name, in this case "usbkey". The rule must be added to the initial ramdisk so it can be read and processed to alias your drive at /dev/usbkey before root decryption is attempted via the key hidden on the drive.

System_Encryption_with_LUKS#Using_udev runs you through the initial steps you need to create a basic rule based on the USB drive's serial number. That is the very same rule I used. I named the rules file "62-usbkey.rules" and placed it in /etc/udev/rules.d/.

Now modify /etc/mkinitcpio.conf, look for the "FILES" section and add the udev rule that you created above:

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options
# like so:
#    FILES="/etc/modprobe.d/modprobe.conf"
FILES="/etc/udev/rules.d/62-usbkey.rules"

Run mkinitcpio ala Mkinitcpio#Image_creation_and_activation and rebuild your ramdisk with the new udev rule you've included. You can now continue to follow the instructions in System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition to modify your bootloader and substitute references to "usbkey" to whatever you named your drive alias above.

S0ma 13:48, 16 December 2011 (EST)

Feature of Grub2 to decrypt /boot

Original comment by Chehri on 8.6.13, moved from [Dm-crypt_with_LUKS#Creating_Disk_Partitions] to here: It is now possible to include /boot on a LUKS container thanks to grub 2.00. Zack Buhman (buhman) has proposed a patch which allows this. This allows kexec to be used to start a new kernel in remote situations. It also removes any possibility of the kernel being tampered with (though grub is still unencrypted; store on a removable drive for added safety).

Interesting patch/idea. I moved the out-of-date box here to discussion first for the following reason:
The patch you link to is proposed and not even commented on, i.e. it is not in the encrypt hook. Having it there as out-of-date in this general Luks section at the beginning will confuse new readers totally. Another reason is that the Luks page in that section is general, not grub specific. Everything there can be setup with standard Arch [core], i.e. also Syslinux.
I hope you agree to that, if not let's please discuss it. Thanks.
I think the best way forward for the contribution would be to draft a subsection under 3.2 (e.g. as 3.2.7), we have different hook modifications there for the swap. (later on there is a specific section on encrypted keyfiles too where it might fit well). Once the section is complete and accurate to modify a standard Arch, one could link to it from the general section above. Once something like that goes into the vanilla Arch-encrypt hook, it should definetely be described earlier. Another (different) point would be to discuss the pros/cons security-wise of such a modification a bit. That could be done in the subsection too. --Indigo (talk) 17:35, 8 June 2013 (UTC)

Encrypting a LVM setup (ex section 8)

The content in sections 8.1 to 8.4 has to be updated, particularly the AIF and /etc/rc.conf references must go. Since another user created a "Encrypted LVM" stub article, which (arguably) has style problems but is a good read otherwise, I see two alternatives for section 8:

A. (1) Remove all outdated install instructions from 8.1 to 8.4, (2) link to the "Encrypted LVM" stub article for users looking for verbose LVM/LUKS install instructions, but (3) keep the LVM short instructions in this article too as a quick reference section. Next, (4) the "Encrypted LVM" should then properly link back properly to the "LUKS" page (particularly to the explanations about the LUKS options)!

B. The second option would be to (5) move the stub article here into section 8, but this would require a major work to make it fit with the rest of the page (double content, a lot of linking up/down).

Both can be done, I prefer A, also because the LUKS page itself is rather huge already. In fact I added links over to that stub page a while back so that new users find it so noone stumbles over /arch/setup et al. Maybe you have another idea than A or B. Opinions? --Indigo (talk) 20:16, 16 July 2013 (UTC)

Yep, if you could take the time to implement A it would be a great improvement. -- Kynikos (talk) 07:42, 20 July 2013 (UTC)
Glad you approve. I have done a re-work today of that; could not wait somehow. Would be good, if someone has a look over it in case I missed out on something. The editing was not that much, more trying not to loose great content which still applies. Still missing is A(4) from above (backlinking from the stub page) and removing the merge-tag in the section (ex sec 8). I also moved some sections to get connected content together (please check TOC). I hope it is not only better in my view. Anyone missing something can find the original section 8 (LUKS-LVM) pasted on my user-page for the time being. --Indigo (talk) 17:44, 20 July 2013 (UTC)
I've taken the time to check your edits (you made it a lot easier by properly commenting really everything), and I like what you've done, it's a very good job!! :)
Yes, A(4) still has to be done, while about removing the Merge template I don't know, maybe "Encrypting a LVM setup" can still be merged to Encrypted LVM, what do you think? (This would be kind of a C. alternative, opposed to B.).
-- Kynikos (talk) 13:51, 21 July 2013 (UTC)
Thanks for taking the time to check it! Currently I would leave it at A as opposed to C, for two reasons: Firstly, the Encrypted LVM works/reads well with the two main setup options shown. Then it picks up different important subjects (gpt, multiple disks) but lacks some of the setup the LVM example this page has (e.g. nowhere on Encrypted LVM you find the word "swap"). So a merge would entail rework of the page in order not to loose content in the merge. Or even adding another example there (better not imho). Secondly, the other installation instructions on this page LUKS#Encrypting_a_system_partition are deliberately describing the simplest encrypted setup. So, the LVM install example here adds options which a reader might want to mix in (e.g. swap, separate /home; maybe those options are worth a mention revisiting it). I think about it again, but currently I would consider the current split easier comprehensible for both pages and outweighing the duplicity (of LVM commands). Any further LVM install tricks should of course be on the other pages, LUKS tricks here. Thoughts? --Indigo (talk) 21:06, 21 July 2013 (UTC)
All right, you convinced me, let's leave it there, thanks again ^^ (this discussion will stay open until all the remaining points are implemented) -- Kynikos (talk) 10:06, 22 July 2013 (UTC)
Okies, I added three (sublime:p) link-backs in the Encrypted LVM howto where I would consider LUKS pointers useful at the least. I will surely revisit the page, but at current A(4) is done from my view. Maybe the merge tag can go for now. Next bits of re-work here on the page may be further streamlining the starting section with better guidance through the page, but that's out-of-bounds this discussion (more the first point on this page). I also marked some old discussions here as closed. It would be nice if you or someone else could look at them sometime and rm as appropriate. Thanks. --Indigo (talk) 20:04, 25 July 2013 (UTC)
Well done, you can remove the merge template and close this discussion then (don't worry, all closed discussions are removed sooner or later). If you will want to discuss more changes to this article, do not hesitate to open another thread. -- Kynikos (talk) 04:51, 27 July 2013 (UTC)

Merge with "plain dm-crypt without LUKS"

Develper has written a new A-Z howto for setting up a plain dm-crypt system, a subject not covered yet in our wiki. It is discussed how to effectively use common content for the benefit of the articles on disk crypto. If you have ideas or thoughts about it, head over: Talk:Plain_dm-crypt_without_LUKS#Merge --Indigo (talk) 21:37, 26 August 2013 (UTC)

Splitting sections into separate pages

Does anyone else feel that 11,305 words is too long for a single article? I'd like to propose splitting this article across multiple pages. If MediaWiki's Subpages feature is enabled, this might be a good time to use it. The article contains many sections that are not greatly related to one another. For example, does one really need to know how to (section 6) encrypt a loopback filesystem or (section 3.2) use a keyfile in order to (section 3.3) encrypt a swap partition? It's common to encrypt a swap partition without using a keyfile or an encrypted loopback filesystem, so why are they discussed in the same article?

I acknowledge that all the sections are related to LUKS, but many of them are not dependent on each other. Having many vaguely related topics makes the article difficult to follow and maintain. I propose Subpages because subpages can show their relationship to LUKS (and other sections, just as an example: /LUKS/Configuration/Keyfiles). In the absence of Subpages, placing a general overview of LUKS in the main article -- and links to pages on more specific topics -- would also be an improvement. Separating sections into (sub)pages would also keep talk pages attuned to a specific subject.

I have some suggestions for improvement of individual sections as well, but I think separating sections would be a good first step. EscapedNull (talk) 14:26, 29 September 2013 (UTC)

Hi, the article is among the longest, splitting it into subpages could help not feeling overwhelmed by it, however a lot of care should be taken in doing it, that's why I think you've been very wise to start a discussion first. We've had a number of users working hard on it, in particular I'd like to point you to a recent discussion I had with User:Indigo, #Encrypting_a_LVM_setup_.28ex_section_8.29, on which we agreed on keeping Dm-crypt_with_LUKS#Encrypting_a_LVM_setup here instead of merging it to Encrypted LVM: moving it to a subpage would somehow conflict with that decision, so I'll try to invite Indigo to discuss here with us on what to do now.
Finally, just to answer your doubts, this wiki doesn't have the subpage feature enabled on the Main namespace, nonetheless subpages (i.e. article names with slashes) are already commonly used to keep series of related articles together, so that would indeed be the way to split this article.
-- Kynikos (talk) 02:54, 30 September 2013 (UTC)
After reading the discussion, I see what you mean. However, I don't think splitting up the article would interfere too much with the decision to keep a brief overview of LUKS and LVM in addition to the Encrypted LVM page. The setup I had in mind was roughly giving each top-level section its own page (but don't quote me on that). The overview and the Encrypted LVM page seem to overlap, and I don't see much benefit to maintaining both, although Kynokos and Indigo might not agree and that's fine. Personally I find the Encrypted LVM page easier to follow and I think it gives the reader a better understanding of the subject, which is why my own edits on the subject have gone there rather than this page. Case and point, I'd propose replacing the overview with Encrypted LVM (as a pseudo-subpage, or just a link), but maintaining the overview is also okay, and perhaps it would just get its own article or pseudo-subpage. The main point I was trying to make is that I think LUKS/dm-crypt is too broad a topic for a single article. And as you said, I'd also be interested in hearing what Indigo has to say about this. EscapedNull (talk) 17:24, 30 September 2013 (UTC)
Hi, thanks for sharing your ideas here. Getting rid of not required content would be a preferable way, if you ask me. Particularly by (a) streamlining to LUKS and vacuuming for clarity. Then (b) splitting content by moving out sections to new pages can help and be a way forward. Yet I don't see a reason why (a) cannot be done while possibilites for (b) are figured out. If you look at the sections you quote in your first post, you will notice 2/3 have short introductory paras and would work as a subpage or even separate pages. Quite a number of edits were made to that respect and continuing with it should make it easier to re-structure the article, if that is the outcome of the discussion. If not, it is still more readable this way.
I don't grasp what you have in mind with replacing the "overview" (?) with Encrypted_LVM. I would rather merge LUKS#LVM:_Logical_Volume_Manager (the "overview"?) to there and link it from here. If you are instead referring to LUKS#Encrypting_a_LVM_setup (and hence the talk quoted by Kynikos above) as the "overview", it would be a great contribution to merge it into Encrypted_LVM. I am sure Kynikos will agree - he proposed to do that originally. In case you would like to approach the merge, please go forward with it. I'll make sure LUKS#Encrypting_a_system_partition regains the cross-linked content.
Back to your original topic:
For (a) maybe you want to re-consider to join in for editing in the suggestions you have in mind first.
For (b) another point that should be addressed along is how the new pages (plain dm-crypt and encrypted LVM) could benefit at the same time. If you ask me now, separating common content would be a preferable approach to using a subpage structure (e.g. like the multipage BG). Perhaps you can detail options you see for (b). How would you re-structure the top sections on this page? Which sections would you fork out from LUKS, ideally with perspective to the other encryption pages? --Indigo (talk) 05:03, 1 October 2013 (UTC)
By "overview" I was talking about section 7 "Encrypting an LVM setup." I didn't even notice that LVM was discussed twice (a testament to disorganization of the page as it is now). I see what you mean about the disadvantages of subpages. I mentioned subpages because, for example, an LVM can be encrypted using almost any block level encryption, and one could argue that setups using different underlying technologies should be separate pages (e.g. LUKS/Encrypted_LVM, Plain_dm-crypt/Encrypted_LVM, and cryptoloop/Encrypted_LVM) as the information is likely to be different (but this could lead to duplicated information, too). It was only an idea, and perhaps something like Category:Disk_Encryption would be more appropriate. After all, subpages are disabled for a reason.
I thought it would be a good idea to split the article first and edit second because it would be easier to focus on a single topic, and because it could save us from editing information twice in case it conflicts with the new structure. But if you think it would be best to edit first and restructure later, I'm fine with that I guess. Kynikos, do you have a preference? EscapedNull (talk) 13:44, 1 October 2013 (UTC)

Confusing sentence

Hi, this sentence "This should be repeated for all partitions except for /boot and possibly swap." is unclear to me; my noobish guess is that it means: "This should be repeated for all partitions and possibly swap, except for /boot" but I am unsure because it appears to mean "except /boot and possibly swap" but I imagine you wouldn't want swap to be unencrypted... Hmm, the more I think about it, it seems both variants seem equivalent though. EmanueLczirai (talk) 01:40, 30 September 2013 (UTC)

Hi, that sentence means that you can't encrypt a boot partition (well, unless you have special hardware) and that you can or cannot encrypt a swap partition depending on how you're going to encrypt your system. Since it seems you are a bit confused on the topic, I suggest you go with the LVM-on-LUKS solution, which will let you encrypt your swap partition and use hibernation and suspension, see Dm-crypt_with_LUKS#Encrypting_a_LVM_setup and Encrypted LVM. -- Kynikos (talk) 03:19, 30 September 2013 (UTC)
Thank you, much appreciated. I'll keep reading, I need to understand more before I go through with any of these. -- EmanueLczirai (talk) 03:26, 30 September 2013 (UTC)

Dual meaning sentence

In this sentence: "Symlinks can be used in the bootloaders "cryptkey" kernel option or anywhere else." Is there a missing comma or apostrophe at the end of the word "bootloaders", or is it "bootloader's" ? Thanks. -- EmanueLczirai (talk) 14:22, 30 September 2013 (UTC)

I think "Symlinks can be used in the bootloader's "cryptkey" kernel option or anywhere else." is what was meant. I doubt bootloaders was meant to be plural, because normally only one bootloader is used on a system. If it were a comma, there would most likely be an article before "cryptkey" kernel option and a comma after option. My interpretation of the sentence is that paths referring to symlinks within the "cryptkey" kernel option of the bootloader configuration will resolve to the file the symlink points to. That's just my two cents; the only way to be sure is to ask the author. EscapedNull (talk) 17:40, 30 September 2013 (UTC)
I'm not the original author, but it is a missing apostrophe as you both guessed. I corrected it: [1]. EmanueLczirai (talk) thanks for pointing it out. If you have more questions or see ambigious wording, please state them here anytime. But please remember to close the discussion point after it has been clarified for you. Closing involves just striking out the heading. Closed discussions will stay for a while they get removed automagically. --Indigo (talk) 13:50, 1 October 2013 (UTC)
Thank you all. Striking as suggested :) -- EmanueLczirai (talk) 23:35, 1 October 2013 (UTC)