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

[Rich Freeman]

On Sat, Jun 6, 2020 at 3:38 PM Victor Ivanov <vic.m.ivanov@×××××.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