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
signature.asc
Description: OpenPGP digital signature
