On Sat, Jun 6, 2020 at 10:07 AM Victor Ivanov <vic.m.iva...@gmail.com> wrote: > > 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.
If you're talking about the drive header that is actually written to disk, it is as secure as the entire drive is, since the drive contains the header. The whole point of full-disk encryption is to keep the contents of the disk secure even if you lose physical possession of the disk. If the password can be brute-forced then the encryption is worthless. Sure, if the attacker has a copy of the header they can spend as much time as they wish brute-forcing it. However, the same is true if they have the entire disk, and that is precisely the scenario we're trying to guard against. If you're using LUKS the security of the system is only as secure as your password(s). LUKS uses a random key to encrypt the drive, and it applies many rounds of encryption to your password to protect the session key. That will greatly slow down a brute force attack. However, if your encryption key is "12345" then a brute force attack is likely to succeed. -- Rich
