Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 06/06/2020 05:37, Dale wrote:
> One other question, can one change the password every once in a while? 
> Or once set, you stuck with it from then on? 

A point I forgot to mention in my previous email is regarding passwords.
While most encryption methods will allow for a password change (CryFS
doesn't) be mindful that with methods used to encrypt large amounts of
data the actual encryption key is generated once at volume creation time
and is never changed. A password is only used to decrypt/derive the key
itself.

This is purely due to practical considerations. If you change the actual
encryption key, then all encrypted data will have to be decrypted with
the old key and re-encrypted with the new key. This may be a perfectly
reasonable thing to do for file-based encryption or small amounts of
data where a password change also means a key change, but is completely
infeasible for larger scale volume encryption that may contain hundreds
of GB of data.

Thus, if a password has been compromised, it is not unreasonable to
assume that anyone who knows the password and has had access to the
encrypted volume might be able to get [or has already got] hold of the
encryption key itself once the volume was opened. Hence, changing a
leaked password doesn't make a compromised volume secure again.

Of course, if it can be safely determined that a leaked password has not
yet been used to access the volume, a swift preemptive change of the
password will retain security.

There is one exception to this where an adversary has a copy of the
header (or similar) of the encryption volume. Here's a quick example
with LUKS. A LUKS volume has a ~2MB header which stores all (hashed)
passwords and the password-encrypted decryption key. The header can be
read and stored separately. In fact, it's good practice for one to back
up the header in case it ever gets corrupted (a corrupt header often
means saying goodbye to your data w/o a backup).

The problem here is that a leaked header immediately means a compromised
volume. An adversary who gets hold of the header can now spend as much
time as they would like to brute force a password (depending on password
strength) and derive the encryption key. Or if they have an (older) copy
of the header with a leaked password before it was changed they can get
hold of the encryption key with virtually no effort at all by using said
password. The only solution to a compromised header is full
re-encryption. Even having a rolling password won't change that.

Bottom line wrt passwords, one should not rely on or assume that having
the facility to change a password will keep their data safe. If using a
password, a strong password is a must.

Again, it boils down to the usual trade-offs, likelihood of physical
access, etc, etc. But I thought it an important point to note, as a
surprisingly large number of people I have spoken to before seem to be
unaware of this caveat (I'm not suggesting you are one of them).

Regards,
Victor