luks2 has grub2 support now, it just needs to enable a specific a specific luksFormat flag
cryptsetup --pbkdf=pbkdf2 luksFormat /dev/...
in addition I think it would be great if there was an SDD option that ran the following options
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue --perf-submit_from_crypt_cpus --persistent open /dev/by-uuid/... ...
and perhaps an in red option for --allow-discards that says warning security implications read the docs, with luks2 on the root that is easier to change so less necessary.
at this point it doesn’t seem like there’s a good reason not to do luks2 in an install.
2 Likes
just hard to convert I think, but I cloned the btrfs, and so I think I’ll be able to get that working.
1 Like
well, should I leave this “open” considering it’s as much of a request for those additional items?
1 Like
Doesn’t that essentially revert one of the main security benefits of LUKSv2 vs LUKSv1? (Argon2id vs PBKDF2)
In other words, might as well use LUKSv1 for root/boot, and reserve LUKSv2 for home, data, and external drives.
1 Like
probably for some level of security, but some of the advantages I’ve found for luks2 is you can change and properties online in a way you can’t do with luks1, I think you can also resize the partition online, IIRC, and some options aren’t persistable in luks1 that are in luks2. Things like luksmeta are no longer necessary. So it’s a lot more flexible. Even if you’ll lose some of the security. Obviously if you have a separate boot, you could only reduce that to pbkdf2. It seems to me, that it only provides benefits, even if you can’t get them all, it’s not reducing them from luks1.
I’ve also thought about requesting an option to do systemd-boot, because of performance reasons when unlocking a fully encrypted drive. Arguably though, unless you sign it, it’s also less secure because the EFI can’t be encrypted, and I believe that also might be a weak area for grub, since it also installs stuff into the EFI partition.
1 Like