How do I determine what ciphers & cipher modes I can use in dm-crypt/LUKS?

I'm using an Ubuntu-based system, and I'm having difficulty determining what ciphers and cipher modes are available to me.

The cryptsetup man page says:

"See /proc/crypto for a list of available options. You might need to load additional kernel crypto modules in order to get more options."

My /proc/crypto has very little in it. How do I find out which extra kernel crypto modules are available for me to load?

Does LUKS encryption affect TRIM? (SSD and linux)

I'm moving over to Linux when the new SSD arrives. SSD gives increased performance, so I thought that I could encrypt everything.

But then I came to think about TRIM, and garbage collection on the drive. Will a LUKS encrypted drive affect the garbage collection system? (TRIM).

How can I use a keyfile on a removable USB drive for my encrypted root in Debian?

Recently set up root encryption with a couple of LVM volumes inside one LUKS volume, and I am just a little confused as to how I would go about getting it to automatically unlock using a keyfile stored on a USB flash drive, I presume I would have to put the drive in the fstab inside my initramfs (if there is one), and add a hook for USB device support.

But I digress, essentially, I want to know what I have to do to enable my LUKS volume (containing all of my partitions sans /boot) to unlock using a keyfile stored on a USB flash drive, rather than a manually entered passphrase.

How to mount an encrypted ext3 filesystem under OS X?

I know how to mount an ext3 filesystem in OS X with MacFUSE and fuse-ext2. But how can I mount an encrypted ext3 volume?

I have Mac OS X 10.6 "Snow Leopard" running.

How can I access volumes encrypted with LUKS/dm-crypt from Windows?

The answer to this question used to be FreeOTFE (https://en.wikipedia.org/wiki/FreeOTFE); sadly, the project has not been updated for three years and its website (http://www.freeotfe.org) is no longer online.

Is there any software available now that can be used to access LUKS/dm-crypt volumes from Windows, now that FreeOTFE is no longer maintained/available?

How to make suspend to RAM secure on Ubuntu with full disk encryption (LVM on top of LUKS)?

I'm on Ubuntu 13.04 using full disk encryption (LVM on top of LUKS).

I would like to incorporate luksSuspend into the suspend procedure (and later use luksResume) so that I can suspend to RAM without leaving key material on memory and the root unlocked.

I've been trying for the last 7 hours to port a script for Arch Linux, so far without success: I honestly have no idea of what I'm doing...

Can anyone help me port this (or create something like this from scratch)? Or, at least, can anyone point me to documentation about how to hook stuff into the suspend procedures and how to keep the necessary binaries and scripts (such as cryptsetup) available even after all IO to root has been blocked (by luksSuspend)?

Concerning how to keep the necessary binaries and scripts available for resume, this other blog post (also for Arch) copied them to /boot; I would like however to use something more in the lines what Vianney used in the script I mentioned before, because that approach appears to be a bit more elegant in this aspect.

TRIM support via dm-crypt/device-mapper

Getting a new laptop with SSD tomorrow. I need to know about the current status of dm-crypt and TRIM. I have seen several conflicting reports and most activity around this question seems to be > 1 year old. Some say that dm-crypt TRIM passthrough has been included in multiple recent kernel versions (which is not a problem for me, since I use Arch). Some say that the support still does not exist. Can I get a clear, well-sourced answer on the status of dm-crypt TRIM support? git commits or mailing list announcements that mention this feature would be ideal.

The answer to this question has big potential to influence the way I architect my new laptop's disks. Hopefully it will be useful to some others to have a decent, up-to-date answer.

Once opened, isn't a volume encrypted using cryptsetup readable by all users?

A volume is encrypted using cryptsetup. Once cryptsetup open ... has been executed, isn't the mapped device then readable by all users on the host? If they know the file system, they can trivially extract contents of all the files.

Googling around, I couldn't figure out why this isn't regarded a problem.

Change the keyboard layout of GRUB in stage 1

I installed grub on a EFI based system. So I have the EFI partition on /dev/sdc2 and my LUKS container in /dev/sdc5. I have only one linux partition in the LUKS container. So even /boot with the stage 2 of grub is encrypted.

When the system boots the EFI boots the grub entry and grub stage 1 loads. This tries to open the LUKS container in /dev/sdc5 and wants a password.

This is the time where I want to have a german layout instead of the english-us one. I know how to change the layout in grub stage 2 but how do I change it in stage 1. Is this even possible?

OS is Debian Jessie.

Why the results of Truecrypt and cryptsetup (LUKS) benchmarking are so different?

I want to encrypt a part of my HDD. But before that I wanted to benchmark the different algorithm available wondering if I should choose aes-xts-256 or aes-xts-512.

Note: I don't have aes hardware acceleration. The benchmarks were repeated multiple times without much change. I'd like to state clearly that these benchmark are only valid on my computer (Debian, core 2 duo). This is not intended to be a complete LUKS-TrueCrypt comparison.

TL;DR: go to part 4

1- Cryptsetup

So I downloaded cryptsetup v1.6.0 to make use of the new cryptsetup benchmark command.

Command

$cryptsetup benchmark

Results

 #  Algorithm | Key | Encryption |  Decryption
     aes-cbc   128b   128,2 MiB/s   157,2 MiB/s
 serpent-cbc   128b    49,6 MiB/s    57,7 MiB/s
 twofish-cbc   128b   138,0 MiB/s   183,8 MiB/s
     aes-cbc   256b    97,5 MiB/s   121,9 MiB/s
 serpent-cbc   256b    51,8 MiB/s    57,7 MiB/s
 twofish-cbc   256b   139,0 MiB/s   183,8 MiB/s
     aes-xts   256b   156,4 MiB/s   157,8 MiB/s
 serpent-xts   256b    55,7 MiB/s    58,7 MiB/s
 twofish-xts   256b   161,5 MiB/s   165,9 MiB/s
     aes-xts   512b   120,5 MiB/s   120,9 MiB/s
 serpent-xts   512b    55,7 MiB/s    58,5 MiB/s
 twofish-xts   512b   161,5 MiB/s   165,3 MiB/s

Thoughts

• In cbc mode, serpent is surprisingly fast at decrypting!
• In xts mode, serpent is clearly the fastest.
• The key size seem to have almost no noticable effect on serpent twofish.
• aes does not behave well when the key size is increased.

Updates out of VM

2- TrueCrypt

I was really surprised as aes is known to be the fastest (even without hardware acceleration). So I downloaded TrueCrypt to double-check these results. TrueCrypt uses the xts mode by default so I assume it also use it in its benchmarks.

Method

1. Tools > Benchmark
2. Choose any buffer size (here, 5MB)
3. Click on "Benchmark"

Results

 #  Algorithm | Encryption |  Decryption
         AES     106 MB/s      107 MB/s
     Twofish      78 MB/s       76 MB/s
     Serpent      41 MB/s       42 MB/s

Thoughts

These results corresponds much more to what is expected but do not match well with cryptsetup's results.

3- General thoughts

• cryptsetup provided better general performance than TrueCrypt in this case. This could be explained the following way:
  • cryptsetup was compiled on my system with compiler optimization routines while TrueCrypt was already compiled in a generic way;
  • AFAIK cryptsetup uses kernelspace crypto modules while TrueCrypt uses userspace crypto routines.
• However, I can't explain why serpent-xts-512 seems to be the way to go with cryptsetup while aes-xts the only cipher worth using.

4- Question

cryptsetup and TrueCrypt give completely different qualitative (relative cipher speed) and quantitative (actual speed of each cipher) results in in-RAM benchmarks.

• Is that something you have already noticed?
• Should I trust cryptsetup and use serpent-xts-512 cipher for speed?

Bad performance with Linux software RAID5 and LUKS encryption

I have set up a Linux software RAID5 on three hard drives and want to encrypt it with cryptsetup/LUKS. My tests showed that the encryption leads to a massive performance decrease that I cannot explain.

The RAID5 is able to write 187 MB/s [1] without encryption. With encryption on top of it, write speed is down to about 40 MB/s.

The RAID has a chunk size of 512K and a write intent bitmap. I used -c aes-xts-plain -s 512 --align-payload=2048 as the parameters for cryptsetup luksFormat, so the payload should be aligned to 2048 blocks of 512 bytes (i.e., 1MB). cryptsetup luksDump shows a payload offset of 4096. So I think the alignment is correct and fits to the RAID chunk size.

The CPU is not the bottleneck, as it has hardware support for AES (aesni_intel). If I write on another drive (an SSD with LVM) that is also encrypted, I do have a write speed of 150 MB/s. top shows that the CPU usage is indeed very low, only the RAID5 xor takes 14%.

I also tried putting a filesystem (ext4) directly on the unencrypted RAID so see if the layering is problem. The filesystem decreases the performance a little bit as expected, but by far not that much (write speed varying, but > 100 MB/s).

Summary:
Disks + RAID5: good
Disks + RAID5 + ext4: good
Disks + RAID5 + encryption: bad
SSD + encryption + LVM + ext4: good

The read performance is not affected by the encryption, it is 207 MB/s without and 205 MB/s with encryption (also showing that CPU power is not the problem).

What can I do to improve the write performance of the encrypted RAID?

[1] All speed measurements were done with several runs of dd if=/dev/zero of=DEV bs=100M count=100 (i.e., writing 10G in blocks of 100M).

Edit: If this helps: I'm using Ubuntu 11.04 64bit with Linux 2.6.38.

Edit2: The performance stays approximately the same if I pass a block size of 4KB, 1MB or 10MB to dd.

Which SSD controllers don't use compression?

I'm in the market for an SSD, but I haven't found any information on which SSDs do NOT use compression on the controller.

The system it will go into requires full disk encryption (provided via LUKS), and many (all?) of the Sandforce controllers end up crippled when they can't compress writes.

Moving a LVM/LUKS encrypted partition to the end of a harddrive?

I need to move a LUKS encrypted partition to the end of a harddrive to expand another partition.
Does anyone know how to do this?

Is it possible to do this with other partition editing programs?

Gparted doesnt support LUKS/LVM

EDIT:
I wrote up a quick tutorial on how I fixed this: http://matthiaslee.com/?q=node/33

pam_mount error "crypt_activate_by_passphrase: Operation not permitted"

I'm trying to set up encrypted home directories on OpenSuSE.

Everything works fine for direct login, but I want the home directories to get mounted via ssh as well. When I try to ssh to the machine, and provide a password, the following shows up in /var/log/messages.

Sep 20 16:03:16 linux-bd9o sshd[11921]: Accepted keyboard-interactive/pam for test from ::1 port 37227 ssh2
Sep 20 16:03:16 linux-bd9o sshd[11921]: pam_mount(pam_mount.c:172): conv->conv(...): Conversation error
Sep 20 16:03:16 linux-bd9o sshd[11921]: pam_mount(pam_mount.c:476): warning: could not obtain password interactively either
Sep 20 16:03:16 linux-bd9o sshd[11921]: pam_mount(mount.c:65): Messages from underlying mount program:
Sep 20 16:03:16 linux-bd9o sshd[11921]: pam_mount(mount.c:69): NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted.
Sep 20 16:03:16 linux-bd9o sshd[11921]: pam_mount(mount.c:69): /usr/sbin/mount.crypt: dmcrypt cipher ignored for LUKS volumes
Sep 20 16:03:17 linux-bd9o sshd[11921]: pam_mount(mount.c:69): crypt_activate_by_passphrase: Operation not permitted
Sep 20 16:03:17 linux-bd9o sshd[11921]: pam_mount(pam_mount.c:521): mount of /home/test.img failed

The same error, crypt_activate_by_passphrase: Operation not permitted, shows up when I try to run

cd /home
mount test.img test

To clarify, I'd like to fix the error first, since I can probably at least follow the SSH recipe given by this sister question, if not modifying /etc/pam.d/sshd. Not being able to mount via command line is annoying.

The key is in CBC. I re-encoded it using these instructions, but the behavior is the same – local login works, SSH or command line mount fails. (Oddly, the octal dump did change, perhaps there is random information to prevent table lookups in the key.)

System encryption LUKS: What's the strongest and most secure key size?

I'm reading an article on the Arch Linux wiki about system encryption, in an example the author specified a 512 bit key. From what I read on Wikipedia regarding encryption ciphers it doesn't seem to be secure enough. That leads me to the question: what's the strongest possible key size?