furrowsofar

I assume it has something to do with how secure boot, the TPM, and Bitlocker interact.

I get it. Credential storage and recovery is a big issue. People vary in skill, ability to keep track of keys or remember how to use them, and they may not have a password manager, safe deposite box, or other locked storage to store them in.

Bittlocker is a pain. Simply booting a maintainance disk requied me to use the recovery codes to get back into windows.

Give her and your personal representatives the keys or access to the keys. Problem solved.

Same problem as you passwords and password manager.

Servers are harder and not preconfigued if you want unattended boot. The first key has to come from somewhere typically to unlock the root partition. The other keys can then be stored on that encrypted partition and are typically referenced by crypttab for auto unlock.

The first key can come from anywhere you want such as attached media like a flash drive, a over the network say via ssh, from a key server, or from the TPM. Or you could remotely connect to the console. There are bunch of how tos out there. It amounts to customizing the boot process and the initramfs. It is not simple. What makes sense depends on the threat model.

Disk encryption does not impact file sharing over the network.

Sure if you sharing by a USB portable drive you have to unlock and lock it every time you use it. That is separate thing though.

The bigger issues of encryption are one should have a good backup and recovery plan both for media and for the keys. One has to consider legacy planning too. How do your personal representatives access.

Your recovery problem was a backup issue not an encryption issue. Consider addressing the backup issue.

Android uses verified boot then encrypts the various profiles and the new private space seprately. This is how my GrapheneOS phone works.

Linux has a bunch of options. Ubuntu use to suggest per user encryption by ecryptfs but has since gone to partition based encryption via dm-crypt/LUKS. I still use either or both depending though ecryptfs seems depricated/discontinued and on the next upgrade I may discontinue.

Linux can support vaults too. Just locking certain folders. Encfs, and gocryptfs can do this for example. I use encfs though perhaps gocryptfs is a better choice these days. One can also use partition based solutions like dm-crypfs/LUKS or maybe even veracrypt too.

This is the primary reason for me as well. Drive disposal. Also since we only get electronic statements, want to encrypt those.

I use hot mount SATA slots for backup and other media. Not that common on workstations. Sure, common on servers.

Yes, that is why I see little value in a TPM for this sort of thing. That is at least for motherboard attached TPMs.

Keep in mind that you have to decide where your going to get the primary unlock key from and how your going to secure it. Standard way is to supply the primary key for the root partition on boot via the console and then the other keys are stored in the root partition.

There are other ways to get the primary key. You can get it from a TPM, a network key server, from other media, etc. These are not standard and have to be set up. What is best depends on threat model.