Also note that nowadays ext4 filesystem natively supports per-directory encryption which may allow a more efficient and better integrated way to encrypt /home.
replying to myself: this is called filesystem-based encryption. Here is the relevant documentation for the part living inside the Linux kernel.
Appears that Android nowadays also uses this for providing user-data encryption (albeit with a different user-space tooling).
As this allows very fine-grained encryption of specific directories only, it may be easier to integrate with LightDM, i.e. maybe not requiring a full restart of LightDM after unlocking just some of the more privacy-relevant directories.
Both recent LUKS versions and fscrypt userspace can process the disk encryption password via Argon 2. If you choose sufficiently CPU-intensive parameters for Argon 2 (e.g. multi-second execution time, 4 CPU threads, 512 MB of RAM), then even a password with 40 bits of entropy will be very costly to break using a GPU based brute-force atttack.
If one believes the (pretty outdated) claims on the argon2-gpu gitlab page, then the Argon2 settings that I use with LUKS on my Volla22:
PBKDF: argon2id
Time cost: 12
Memory: 500000
Threads: 4
only allow for roughly 8 password attempts per seconds when brute-forcing on a NVIDIA Tesla K20X. That's only 2^28 password attempts per year and GPU!?
Note that Argon2 support in LUKS is not available on the older 16.04 version of UBports, you need 20.04 (focal).
