On Sat, Jun 6, 2020 at 3:38 PM Victor Ivanov <vic.m.iva...@gmail.com> wrote: > > On 06/06/2020 19:51, Rich Freeman wrote: > > 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. > > Not true. A key file stored outside the header is arguably way more > secure than a password - there's no longer a single point of failure. > Then there is also the option of having a detached LUKS header that is > never written to the block device in the first place which effectively > leaves the adversary with a stolen brick.
Maybe we're miscommunicating, but it seems like you're moving the goalposts here. My point remains: The header is as secure as the disk. If the disk is secure against brute-force, then so is the header. Your original point was, "The problem here is that a leaked header immediately means a compromised volume." This makes no sense. The whole reason you're using encryption is to protect the data if your disk is stolen/etc. If they steal the disk they get the header too. So, if a leaked header means that your volume is compromised, then a stolen disk does so as well, which means your encryption is worthless. Now, obviously if you don't store the key in the header or store the header on the disk, that is more secure. However, if the key isn't in the header then a leaked header does not give an attacker any opportunity to brute-force it, because there is nothing to brute force. There are many things that can be done to make the disk more secure, like not using a memorable password or not storing the key on the disk. Obviously these sorts of solutions create additional problems with key management, and if you solve them incorrectly then you might actually reduce security. > I was merely emphasising the fact that > when using a password, having the facility to change the password can > give a false sense of security Sure, there is really no point in "rotating passwords" with LUKS. If somebody gets a copy of your disk then they effectively have a snapshot of your password. If you later change it the data they still have a copy of what it used to be. And if they do have the ability to periodically snapshot your header and you keep changing your password, then they can bruteforce all your passwords in parallel and if they obtain any of them they can decrypt the drive, unless you change the session key and re-encrypt the drive. With any of these things you have to understand your threat model. For example, on my distributed filesystem I'm moving to encrypted drives to protect me in case I have to dispose of a drive without the opportunity to wipe it first. To do this I'm just going to store my keys on the root filesystem so that the systems can be booted without interaction. Obviously if somebody compromises the files with the keys they can decrypt my drives, but this means that I just have to protect a couple of SD cards which contain my root filesystems, instead of worrying about each individual hard drive. The drives themselves end up being much more secure, because the password used to protect each drive is random and long - brute-forcing the password will be no easier than brute-forcing AES itself. This doesn't protect me at all if somebody breaks into my house and steals everything. -- Rich
