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