On Tue, Sep 19, 2023 at 4:26 AM Michael <confabul...@kintzios.com> wrote: > > On Tuesday, 19 September 2023 06:36:13 BST Dale wrote: > > Howdy, > > > A strong > password, like a strong door lock, buys you time. Hence the general > recommendation to change your passwords frequently.
While that can help on websites, it is of no use for full disk encryption passwords - at least not without jumping through some big hoops. In order to crack your LUKS password somebody obviously needs to be able to read the encrypted contents of your disk. They cannot begin cracking it until they have a copy of the LUKS headers. However, once they do have it, they can make a copy and crack it at their leisure. If they manage to crack it, then it will give them the volume key. At that point if they were able to make a full copy of your disk they can read whatever was on it at the time. If they can make a fresh copy of your disk then changing the passphrase will not change the volume key, and so they'll be able to read what is currently on your disk. Changing the volume key would defeat this, but requires running cryptsetup-reencrypt which will take considerable time/CPU, though it sounds like it can be done online. > > In the real world tho, how do people reading this make passwords that no > > one could ever guess? You didn't ask this question, but I'll just note that most organizations don't use human-readable passwords to implement full disk encryption. The most commonly used solution is to use a TPM to measure the boot process and secure the disk encryption keys. If the system is booted normally, the bootloader can read the encryption keys from the TPM and can decrypt the disk without any user interaction (or even awareness it is happening). If the system is booted from alternative media, or the on-disk bootloader is tampered with, or even if the firmware is tampered with, then the TPM measurements will not agree with those used to store the key, and the TPM will not allow the keys to be read. This is how solutions like Bitlocker work. The components for this exist in the Linux world, but I'm not aware of any distro/etc actually implementing this with a pretty front-end, and there are obviously details that need to be carefully handled so that a bootloader or firmware update doesn't render your disk unreadable. Typically software implementations have ways to store "recovery keys" for these situations (just another copy of the disk key stored outside the TPM). > You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate > random enough strings to use as passwords. You might want to also consider app-admin/xkcdpass > > Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is > > that 512 a good number? Can it be something different? I'd think since > > it is needed as a option, it can have different values and encrypt > > stronger or weaker. Is that the case? I've tried to find out but it > > seems everyone uses 512. If that is the only value, why make it a > > option? I figure it can have other values but how does that work? You can use a different size, but 512b is the recommended value for the default cipher. It is also the default I believe, so there isn't much point in passing it. Actually, I'd consider passing that parameter harmful unless you also specify the cipher. If in the future the default changes to some other cipher, perhaps 512b will no longer be appropriate, and you'll weaken it by specifying one and not the other. If you just want to trust the defaults, then trust the defaults. As to why 512b is the recommendation, that seems like it would require a LOT more reading. Apparently it is in an IEEE standard and I'd need to grok a lot more crypto to appreciate it. -- Rich
