On Sat, Sep 23, 2023 at 11:05 AM Dale <rdalek1...@gmail.com> wrote: > > I'm not to clear on this but it looks like it is using 'aes-xts-plain64' > to me. If so, is that good enough? Is there better?
You are using the defaults, which is what you should be using, as they're very secure. As far as I'm aware there is no known attack on AES that is faster than a brute force attack, and a brute-force attack on AES itself is not practical. I think it is unlikely that anybody knows of an attack on the cipher, but of course that cannot be ruled out. Current estimates of the time required to brute-force AES are in the billions of years. If somebody wanted to decrypt the drive without your knowledge, the only practical attacks would be to evesdrop on you somehow to capture your passphrase, or to brute force your passphrase. LUKS is designed to make a brute-force attack on a passphrase impractical as long as it is reasonably long. On typical hardware it should take a full second or two to make one decryption attempt on the passphrase - obviously an attacker could have more sophisticated hardware available but to even be able to attempt tens of thousands of guesses per second would require a very large expense, and your passphrase should be long enough to make that search very long. The most likely attack would be evesdropping. Stopping that requires good physical security, and also keeping any malware out of your bootloader. Unfortunately, the latter is generally not something linux distros do much to prevent. Corporate laptops running windows are typically set up to protect against this using a TPM and secure boot. I'm not sure if any linux distros support a fully signed boot processes up to disk decryption - doing that on Gentoo would be tricky since the OS is being modified so often. A release-based distro could do it a bit more easily - just stick the essential bits in a squashfs and sign everything up to that point, and use secure boot. Then of course if an attacker didn't mind you knowing about their intrusion, they could use the rubber hose method. The only way to defeat that sort of thing is to have some trusted external agent involved in the process who could revoke your own access to your device (think TPM and remote attestation to secure the boot chain plus online authentication required for the device to obtain the session key - though at that point you'd probably also just run a thin client and keep the bulk of the data someplace more secure). -- Rich
