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