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

[Victor Ivanov]

On 06/06/2020 19:51, Rich Freeman wrote:
> 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.

I never said it was any less secure. It would be daft to even assume
something like that as it's de facto the door to the encrypted data.

The point I was making is simply that it increases the risk of data
breach when a password is used, especially if (one of) the password(s)
has been or is subsequently compromised. After all, it's difficult to
remember passwords that are long enough and have high entropy. There are
also the practicals inconveniences of having to type a long password.

On 06/06/2020 19:51, Rich Freeman wrote:
> If the password can be brute-forced then the encryption is worthless.
> ...
> 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.

Hence my previous point on ensuring a strong password.

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.

Are any of the "more secure" setups inconvenient to use? Sure. And I
doubt the average person would be that paranoid to use a detached
header, which by itself introduces a whole lot of issues like how do you
store the header itself securely. 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 in a select number of cases, especially
if the password being used prioritises memorability over sophistication,
often leading to low entropy, and that this is particularly problematic
for leaked passwords as brute-forcing high entropy passwords is not
feasible anyway as per your own words.

Regards,
Victor