: I have now merged the generic disk encryption info from this article's intro section (which turned out to be a ''lot'') into the [[Disk_Encryption]] article. Please review, and improve where appropriate. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 12:43, 4 July 2012 (UTC)

: I have now merged the generic disk encryption info from this article's intro section (which turned out to be a ''lot'') into the [[Disk_Encryption]] article. Please review, and improve where appropriate. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 12:43, 4 July 2012 (UTC)

::I think it's been a very good job, Sas. I've just done the linking and renaming part, closing this discussion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:25, 6 July 2012 (UTC)

::I think it's been a very good job, Sas. I've just done the linking and renaming part, closing this discussion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:25, 6 July 2012 (UTC)

+

+

== Specifying skip and count in /etc/crypttab for /tmp ==

+

In the wiki, 8.3.5.5 /etc/crypttab, you're advised to put the following in your /etc/crypttab

+

+

tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512

+

+

But doing that will not work. More specifically in /etc/rc.d/functions:do_unlock() in switch case /dev/*. After debugging with some `set -x`:es I found that if you specify the dd count and skip parameters in crypttab it will work i.e., e.g.,

+

+

tmp /dev/lvm/tmp /dev/urandom:2048:2048 -c aes-xts-plain -s 512

+

+

If this is how it should be done I propose a change in the wiki to consider this. If not, do_unlock() is strange.

Cleanup and Clarification

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)

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)

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?

Suspend to disk instructions are insecure

They cause the swap encryption key to be picked up by mkinitcpio and stored on the unencrypted /boot partition, thus rendering the encryption useless. Better still, the suspend image contains the keys for any other encrypted partitions that were currently open too...

Unless someone thinks otherwise, I'm going to remove the stuff about key files and replace it with a warning not to do that. I think the approach using a password should be secure, and it's somewhat workable (at least in my setup with uresume): we can place the 'openswap' and 'uresume' hooks before 'encrypt' and rely on the above-mentioned keys in the suspend image to magically have the root unlocked once the resume is complete. Downside is typing two passwords during a normal boot - it's a quick fix for the current instructions at any rate.

There are a few other options, but probably the tidiest strategy would be to put root and swap (and anything else) on an encrypted LVM PV, then the 'encrypt' hook can unlock everything in one go. I guess that makes a mess if the VG contain other PVs which need decrypting too, but that's probably not an issue at least for laptop users. I've not tried this though.

Of course, ideally there'd be support for multiple volumes (preferably with a single password prompt) in the 'encrypt' hook.

Is there a fix for this yet? Maybe the luksSuspend function? --Revelation60 21:21, 20 December 2010 (GMT+1)

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.

Wouldn't it make more sense to completely remove it from the article instead? Seeing as it apparently provides no security benefit compared to using zero bytes... --Sas (talk) 12:39, 4 July 2012 (UTC)

At the same time, using badblock to erase data has no major problem. In Arch the decision should be made by users themself. -- Fengchao (talk) 04:41, 5 July 2012 (UTC)

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.

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)

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 ;-).

Backup of volume header

I think that its important to backup headers of your volumes. This should be mentioned in the wiki imo.

LVM2 and LUKS

I'm quite sure this section is misleading. You have to setup up encryption before LVM2 partitions on the decrypted device.

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 ?

- 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.

Prepare hard drive

The actual text is:

Skip the Partitioning and Auto-Prepare business and go straight to "Set Filesystem Mountpoints". When asked for your / (root) partition, do NOT select /dev/sda3 as you normally would. Select /dev/mapper/root instead. Similarly, use /dev/mapper/home instead of /dev/sda4 as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition. Make sure you mount /dev/sda1 as the /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 / (root) partition: is it /dev/mapper/root or /dev/mapper/lvm-root. I suppose it is the first one because the second one does not match.

on the bashing of /dev/urandom

I don't take an opinion on whether old overwritten data can be read.

However, there is an unrelated reason to fill a LUKS partition from /dev/urandom before LUKS-initializing it (and after checking for bad blocks if you wanted to do that).

It makes it harder for people trying to read your disk and find out what's on it. If you filled it with zeroes, for example, then they would be able to tell which portions of the partition had been written to since you initialized it.

Agreed, /dev/urandom should be used to clear partitions, at least as default in the examples. If anyone wants to zero the partitions instead of using random data, they are free to do so. --Montschok 20:53, 11 August 2010 (EDT)

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.

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"

Moving the "why should I use encryption" section to a separate article

The section "Why should I use encryption" is referenced by other encryption-related articules (like this one.
I'd like to move this to a separate article, since it treats subjects related to encryption in general, not especifically just LUKS. Is everyone ok with this? Hobarrera (talk) 02:00, 11 June 2012 (UTC)

It would be great if we could have a generic article introducing to system encryption with content taken from the currently existing articles. User:Fengchao has proposed to move User:Sas/Disk Encryption to a regular article and use that as a start, and I concur, what do you think? -- Kynikos (talk) 09:17, 12 June 2012 (UTC)

The section to be moved contain many information about "data encryption". System Encryption is too restrict about them. How about add link and short introduction about Secure Shell in the article ? That way the new article will be the most general introduction. -- Fengchao (talk) 04:35, 16 June 2012 (UTC)

Besides, more important, the Encryption article should probably be linked from all its related articles, so that we can prevent users from adding generic information to those articles in the future, but direct them toward the general article.

I have now merged the generic disk encryption info from this article's intro section (which turned out to be a lot) into the Disk_Encryption article. Please review, and improve where appropriate. --Sas (talk) 12:43, 4 July 2012 (UTC)

I think it's been a very good job, Sas. I've just done the linking and renaming part, closing this discussion. -- Kynikos (talk) 15:25, 6 July 2012 (UTC)

Specifying skip and count in /etc/crypttab for /tmp

In the wiki, 8.3.5.5 /etc/crypttab, you're advised to put the following in your /etc/crypttab

tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512

But doing that will not work. More specifically in /etc/rc.d/functions:do_unlock() in switch case /dev/*. After debugging with some `set -x`:es I found that if you specify the dd count and skip parameters in crypttab it will work i.e., e.g.,

tmp /dev/lvm/tmp /dev/urandom:2048:2048 -c aes-xts-plain -s 512

If this is how it should be done I propose a change in the wiki to consider this. If not, do_unlock() is strange.
--Erikw (talk) 16:40, 17 July 2012 (UTC)