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