How to change luks encryption difficulty on manjaro full disk encrypt

encryptionluksmanjaro

I am using manjaro with full disk encrypt, however, the wait time at boot for decrypt is very long ( i assume because of a high difficulty setting) . How can I change encryption difficulty/ wait time of the encryption setup during install?

Best Answer

Too much passphrase hashing?

If it's only slow because you're waiting for a lot of passphrase hashing iterations, you could add a new passphrase with a quicker --iter-time, but that could reduce security & allow faster guessing of passphrases. If you wanted to wait 1 second (1000ms) then use a command like:

cryptsetup -v luksAddKey --iter-time 1000 <device>

You might then have to delete the old slow passphrase (with luksKillSlot), unless it's key slot is after the new quick one (they're apparently tested in order, so might have to wait for the first slow slot to be tested before the later quick one). Or change your initial open command to specify the new quicker --key-slot number.

The luksChangeKey command can combine the two steps, adding a new key then deleting the old key (even though the v1.7 man page doesn't specifically say it can use --iter-time, apparently it can):

cryptsetup -v luksChangeKey --iter-time 1000 <device>

How slow is it now?

Test how long it takes to decrypt / open your device with:

cryptsetup -v luksOpen --test-passphrase <device>

Or test a specific key slot with the --key-slot option:

cryptsetup -v luksOpen --test-passphrase --key-slot N <device>

Using the time command might help, but also count your typing speed.

You can use the luksDump command to see what the current key slot Iterations: are, this is an example of a very slow slot 0 and a very quick slot 1:

Key Slot 0: ENABLED
    Iterations:             4663017
    Salt:                   ......
    Key material offset:    8
    AF stripes:             4000
Key Slot 1: ENABLED
    Iterations:             1000
    Salt:                   ......
    Key material offset:    264
    AF stripes:             4000

From man cryptsetup:

--iter-time, -i

The number of milliseconds to spend with PBKDF2 passphrase processing. This option is only relevant for LUKS operations that set or change passphrases, such as luksFormat or luksAddKey. Specifying 0 as parameter selects the compiled-in default.

luksChangeKey <device> [<new key file>]

Changes an existing passphrase. The passphrase to be changed must be supplied interactively or via --key-file. The new passphrase can be supplied interactively or in a file given as positional argument.

If a key-slot is specified (via --key-slot), the passphrase for that key-slot must be given and the new passphrase will overwrite the specified key-slot. If no key- slot is specified and there is still a free key-slot, then the new passphrase will be put into a free key-slot before the key-slot containing the old passphrase is purged. If there is no free key-slot, then the key-slot with the old passphrase is overwritten directly.

WARNING: If a key-slot is overwritten, a media failure during this operation can cause the overwrite to fail after the old passphrase has been wiped and make the LUKS container inaccessible.

It's not the passphrase hashing?

There's lots of reasons for a slow boot time, maybe it's unrelated to the encryption.

Or if the actual encryption/decryption itself is too slow, then changing the algorithm or key size might be required, and that would require decrypting and re-encrypting everything. There are programs (or commands in newer versions) that can do it in-place, hopefully without losing anything, but having a backup would be more than an excellent idea.

But in that case, it wouldn't just be a long initial wait but all reads & writes would be a little slower.

You can use the cryptsetup -v benchmark command to see some speed tests, but "NOTE: This benchmark is using memory only and is only informative. You cannot directly predict real storage encryption speed from it."

Related Solutions

How to get a usable full disk encryption with different encryptions for different users

Don't encrypt the whole hard drive (as in /dev/sda, do it per partition (or more precisely per file system - see below).
Have separate file systems mounted at homes for the two users. I'm intentionally avoiding writing separate partitions, since while that is the usual way of doing things, it is constraining in some aspects. It might be more convenient to have one large home partition, which holds big files that contain the encrypted file systems and are mounted as necessary. The advantage is easier resizing of users' homes while keeping them separated.
Automounts on login are possible through PAM. Note that you don't want to use the same password for login and for the actual data encryption. Instead, you either use LUKS or imitate it by storing the encryption key in a file that itself is encrypted with the login password. That ensures that a change of the login password won't affect the encrypted data but only the encrypted key and thus yo won't have to take care of re-encrypting whole users home).

General instructions:

partitioning use gdisk (also known as gptfdisk sometimes), parted or any other appropriate program, read man pages for details (partitioning is a bit out of scope of this QA)
encrypted file-based file systems - I have some objections to the design of LUKS, so I'm generally using cryptsetup in the "plain" mode, which imitates LUKS in some aspects. If you choose LUKS, than you can just reduce the steps to the cryptsetup (with appropriately modified options)
1. prepare the encryption key and password. This is an interesting part - for encrypting the data you want something with enough randomness (8 letter password really isn't enough) and for password something that you can change easily (without needing to re-encrypt the whole filesystem) and is reasonably easy to remember and type in. These requirements go quite against each other. Hence we'll use the same trick that LUKS does (and which can actually be considered a variation of a hybrid cryptosystem in some sense)). The encryption key can be more or less random - either use some really random data (e.g. from /dev/random), or a reasonably long hash like SHA-2 or SHA-3 (the first one was designed by NSA, if you wonder whether to use it or not in light of the recent events) of a reasonably long passphrase.
  
  Reasonably long in the first case (and in the case of really random data) means, that the length should be about the chosen key length for the cipher used plus the length of the initialization vector. In the second case it means that it should be difficult to brute-force it. Using a hash has the advantage of being able to recover the key if it gets damaged or lost (provided you remember the initial passphrase that was hashed, of course). This key is then encrypted and stored in a file. The passphrase for the encrypted key in your case will be the same ass the login password.
```
# set up the encrypted encryption key
printf "Reasonably long and complicated passphrase" \
    | openssl dgst -sha512 -binary \
    | openssl enc -bf > /path/to/key.enc
```
  openssl dgst -sha512 -binary produces binary form of the SHA-512 hash from its standard input, openssl enc -bf encrypts it using Blowfish - feel free to choose hash and cipher to your liking (Twofish or Rijndael are both rather well-tried, but other ciphers available in the kernel should be fine too).
  
  Keeping the key outside of the encrypted device has a disadvantage of needing additional thing apart from the encrypted data itself - LUKS stores the key in its headers, so it's self-contained. On the other hand you are bound to a particular set of tools. While it is not designed carelessly and is present on most installations, you need the special tools to access it.
  
  With a separate file on the other hand, you are free to choose any method of storing the key. You can even put it on removable media, insert it before login and remove it once the file system is mounted (you could probably even hook automatic login on the event of attaching the media to the computer). Of course all this should be well thought through since the security maxim "Do not invent your own crypto" applies (see e.g. this post on Security SE) - which might actually be an argument for using LUKS. Backing up the key is obviously easy.
2. create an empty file that will hold the file system
```
dd if=/dev/zero of=/path/to/backing_file.enc bs=1M count=X
```
3. create the encrypted device
```
openssl enc -bf -d -in /path/to/key.enc 2>/dev/null \
    | cryptsetup create \
            -c twofish-cbc-essiv:sha256 \
            -s 256 \
            -h plain \
            encryptedfs /path/to/backing_file.enc
```
  openssl enc -bf -d asks for password on stdin and tries to decrypt the encryption key. cryptsetup create ... encryptedfs /path/to/backing_file.enc created encrypted DM device called encryptedfs backed by the previously created file. Important option it the -c which selects the encryption cipher and its mode of operation
4. fill the device with zeros - this effectively puts "random garbage" into the backing file and makes it less obvious, what the contents of the file might be (otherwise, you could tell where things have been written by scanning for blocks that are not zeroed from step 2).
```
dd if=/dev/zero of=/dev/mapper/encryptedfs bs=1M
```
5. Create a filesystem
```
mkfs.[favourite_filesystem] [tuning options] /dev/mapper/encryptedfs
```
6. Put a corresponding line into /etc/fstab in case you want to do everything on your own, or into /etc/crypttab if you want some sort of integration with system tools.
for automatic (un)mounting on login/logout, I'll refer you to the pam_mount documentation.

Ubuntu – Full disk encryption with dm-crypt (without LUKS)

According to initramfs-tools(8), one can add programs to the initrd image by adding e.g. the following to a hook script:

copy_exec /sbin/cryptsetup /sbin

Example hook scripts can be found in /usr/share/initramfs-tools/hooks and on my Ubuntu system, /usr/share/initramfs-tools/hooks/cryptroot is indeed adding /sbin/cryptsetup to the initrd image.

Example:

$ gzip -dc /boot/initrd.img-`uname -r` | cpio -tv 2>/dev/null | grep cryptsetup
=> No cryptsetup included, yet.

$ cat /etc/initramfs-tools/hooks/fde
#!/bin/sh

. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/cryptsetup /sbin

$ sudo chmod 0755 /etc/initramfs-tools/hooks/fde
$ sudo update-initramfs -u

$ gzip -dc /boot/initrd.img-`uname -r` | cpio -tv 2>/dev/null | grep cryptsetup
-rwxr-xr-x   1 root     root        59248 Aug 21 04:04 sbin/cryptsetup
-rw-r--r--   1 root     root       158848 Aug 21 04:04 lib/x86_64-linux-gnu/libcryptsetup.so.4