On 06/06/2020 12:05, Rich Freeman wrote: > Usually you want the encryption as close to the disk as possible > because if somebody gets your disk it gives them less to work with. > They don't know that you have a logical volume called "home" on it, > and so on.
I concur with Rich on this. One of the key considerations for encryption is how much is it that want encrypted and what metadata are you willing to have publicly visible. As an extreme example, you can think of the simplest form of encryption - on a per file basis. Contents are encrypted, but things like file name and size, creation and modification timestamps, filesystem directory tree are all available to an imaginary adversary. One can further deduce information about the file by its extension, and use all of that to come up with a good attack strategy for decryption. In other cases, contents may be irrelevant to an adversary, as they can already infer a lot about a person - if that's what they are interested in - from directory listings etc, depending on what they are looking for. Filesystem-based support for encryption will inevitably leak some metadata. On the other extreme you have block-level encryption which hides all contents, including filesystem information, for a given block device. With multiple physical partitions, however, this too can leak a degree of information. For example, it would be reasonable to assume that the largest partition is a person's "storage" partition. So attempts can be targeted at that block device, ignoring all other ones. It's also cumbersome to manage as unlocking multiple block devices would require multiple password entries unless a common key file is used. Michael mentioned CryFS which is kind of in the middle. It's an "overlay" filesystem, anything within a CyFS volume is encrypted into fixed-size (e.g. 64KB) block files. This includes file names and all file meta data, directory structure, etc., and all encrypted content can be interleaved across different blocks. However, depending on the size of the average files you have, it can have a significant overhead where contents of the encrypted CryFS volume can be considerably larger than the actual contents of your encrypted data. This can addressed, to a degree, by playing with the block size. Smaller block size will reduce overhead but will increase the number of block-sized encrypted files on the actual filesystem, which can eat up a lot of INodes. The downside is, the block size cannot be changed once a CryFS volume is created, and neither can the password. These require creating a new CryFS volume and migrating your files. As such, my personal view on the matter is that CryFS is usually good for small volumes and is indeed very good for securing content on cloud services like Dropbox that do not normally encrypt your data. Personally, I have been using LUKS and LVM for many years. On OS-bearing drives I would have a non-encrypted /boot partition for the kernel and initrd whilst the remainder of the drive would be a LUKS encrypted block device - two partitions in total (3 for a GPT system). Within the latter, I would create LVM partitions as I desire (including OS root). LUKS has 8 slots that can hold up to 8 passwords or key files (or any combination of both) at a time. This set up is pretty much zero-leak. For an external drive I would use LUKS across the whole drive. Note in the former case the /boot partition is still vulnerable and a compromised kernel image could lead to a leaked LUKS password once the LUKS block device is opened. Signing the kernel and its modules is one possible solution. At the end of the day, which method you choose is based on a balancing trade-offs and likelihoods of an attack. That said, virtually all modern processors in the last 10y or so have native hardware extensions for accelerating common encryption algorithms such as AES. As such, having full-disk encryption has very little performance overhead on read/write speeds. You can use "cryptsetup benchmark" to see upper bound estimates of read/write speeds. The values shown are in-memory estimates and are thus CPU/memory bottlenecked. For example, on one of my systems with a mobile i7 CPU AES with 512b key (maximum supported by LUKS with AES) shows about 2,000MB/s for both read/write. This is more than enough to saturate a SATA3 drive's 6Gb/s best-case data rate as well as a lot of current generation consumer grade NVMe drives. In summary (and final remarks): * Performance overhead these days is largely irrelevant for common use cases * Use case (e.g. cloud storage or local drives) and what is left behind unencrypted is a key consideration when choosing a method. * Generally, block-level encryption is preferable to filesystem encryption * LUKS is Linux-specific. If cross-platform compatibility is required this won't be a good choice. Then again, so is LVM. * TrueCrypt is obsolete - do not use this if you can avoid it * VeraCrypt (its successor) is cross platform. Probably a good choice for block-level encryption between different OS [I haven't personally tried this]. Hope this helps. - Victor
signature.asc
Description: OpenPGP digital signature
