Gentoo Archives: gentoo-user

From: Victor Ivanov <vic.m.ivanov@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Date: Sat, 06 Jun 2020 14:08:10
In Reply to: [gentoo-user] Encrypting a hard drive's data. Best method. by Dale
1 On 06/06/2020 05:37, Dale wrote:
2 > One other question, can one change the password every once in a while? 
3 > Or once set, you stuck with it from then on? 
5 A point I forgot to mention in my previous email is regarding passwords.
6 While most encryption methods will allow for a password change (CryFS
7 doesn't) be mindful that with methods used to encrypt large amounts of
8 data the actual encryption key is generated once at volume creation time
9 and is never changed. A password is only used to decrypt/derive the key
10 itself.
12 This is purely due to practical considerations. If you change the actual
13 encryption key, then all encrypted data will have to be decrypted with
14 the old key and re-encrypted with the new key. This may be a perfectly
15 reasonable thing to do for file-based encryption or small amounts of
16 data where a password change also means a key change, but is completely
17 infeasible for larger scale volume encryption that may contain hundreds
18 of GB of data.
20 Thus, if a password has been compromised, it is not unreasonable to
21 assume that anyone who knows the password and has had access to the
22 encrypted volume might be able to get [or has already got] hold of the
23 encryption key itself once the volume was opened. Hence, changing a
24 leaked password doesn't make a compromised volume secure again.
26 Of course, if it can be safely determined that a leaked password has not
27 yet been used to access the volume, a swift preemptive change of the
28 password will retain security.
30 There is one exception to this where an adversary has a copy of the
31 header (or similar) of the encryption volume. Here's a quick example
32 with LUKS. A LUKS volume has a ~2MB header which stores all (hashed)
33 passwords and the password-encrypted decryption key. The header can be
34 read and stored separately. In fact, it's good practice for one to back
35 up the header in case it ever gets corrupted (a corrupt header often
36 means saying goodbye to your data w/o a backup).
38 The problem here is that a leaked header immediately means a compromised
39 volume. An adversary who gets hold of the header can now spend as much
40 time as they would like to brute force a password (depending on password
41 strength) and derive the encryption key. Or if they have an (older) copy
42 of the header with a leaked password before it was changed they can get
43 hold of the encryption key with virtually no effort at all by using said
44 password. The only solution to a compromised header is full
45 re-encryption. Even having a rolling password won't change that.
47 Bottom line wrt passwords, one should not rely on or assume that having
48 the facility to change a password will keep their data safe. If using a
49 password, a strong password is a must.
51 Again, it boils down to the usual trade-offs, likelihood of physical
52 access, etc, etc. But I thought it an important point to note, as a
53 surprisingly large number of people I have spoken to before seem to be
54 unaware of this caveat (I'm not suggesting you are one of them).
56 Regards,
57 Victor


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-user] Encrypting a hard drive's data. Best method. Rich Freeman <rich0@g.o>