I came back to this post and took a look at the suggested tools. Those are working with adaptive volume encryption, which makes them indeed way more practical from a size allocation and data backup point of view.
I ran some tests with encfs and cryfs, there are less steps to be taken to perform the initial setup, as well as for mounting/unmounting.
There is a nice comparison table here between different tools. Some of them appear to have security issues/concerns, so one should choose wisely.
That is not good enough on modern SSD’s. They hide storage from the OS that can have data leaked that you would like kept secure.
Use Full-Disk-Encryption is the best way if you care to not leak data when your system is at rest.
In the days of HDD’s a single write over files is not good enough to prevent recovery of the previous data on the disk. There is history in the magnetic domains that can be read to get the data of previous writes back.
There is a FIPS standard that involved write specific patterns over the blocks 13 times to give a reasonable chance to prevent recovery of data.
In my previous day job all SSD’s and HDD’s where sent to be ground up into iron filling sized bits. Even FIPS erase was not trusted.
Understanding the nature of how the SSD’s do wear leveling, enabling/disabling TRIM are topics I can go into, but would certainly derail this thread. Essentially one or both of these can harm Full Disk Encryption too. . .
I digress, I’ve made my points about an encryption solution, that is also OS agnostic and viable at rest. I have other encryption solutions I lightly detailed as well. I think the OP’s model was identified. Their choice now.
Wow, the things you can learn scanning through random help threads! And, just for the sake of absolute clarity for the less-educated among us (like myself!), when you say this:
So in the diagram above, The Full Disk encryption would require you to open the Container to expose all partitions within.
In a Parttition based encryption you would need to decrypt all blocks to access all the data. This also becomes a nightmare if you ever have issues with the partitions. You need to know what passwords are for each Block and have all the Luks Headers and keys backed up in case of recovery. Including information on the UUID of each one.
It’s worth mentioning that with Fedora fresh install, at the pre-installation setup stage, if the user opts for encryption and default disk partitioning, then a partition-based encryption takes place. Root/Home partition will be encrypted, while /boot and /boot/efi partitions will not.
The reason I asked was because the OP may not want to dedicate the entire disk to encryption to do what he’s looking to do, and it would create some headaches should they want to boot off of that disk anyway. (Not that it couldn’t be done!)
He could instead create the space, then a separate partition on his current disk, and encrypt that. Full-disk only sorta rules out that path.
Yeah I see your point, I was once there and then space became an issue on the drive. So I decided to do as some of the above examples on creating a Vault with LUKS in some directory. Which added the ability to move it if need be. Which can now be achieved with something like KeepassXC.
That works, but I think full disk encryption is still the better solution. Applications often create cache files or copies for other reasons. Its a problem if these get written to an unencrypted partition.
Lets say we have some pictures on a secondary encrypted partition. All it would take to leak unencrypted copies to the main partition (~/.cache/thumbnails) is looking at them using the file manager because of thumbnail generation. I could give more examples, but I hope this proves the point I am trying to make. If your main partition is not encrypted there is a very high chance that at some point you are going to accidentally create an unencrypted copy. Probably without you even realizing it, and even if you did it will be very hard to make the unencrypted copy unrecoverable (as discussed above).
Because of this I really don’t recommend creating a secondary encrypted partition, just go with full disk encryption. Yes it will require a password when booting, but that password will be required anyway when accessing the partition.
