18Eyl
In Linux, what encryption implementation approach is optimal given specific use & threat models?
Given the following use & threat models, what is the optimal encryption implementation? Optimal is defined as the approach best matching the use model.
Use Model
- Computer must be optimized for performance.
- Computer use will include significant data reads and writes, including both small and large block reads/writes.
- Storage space (SSD) will be at a premium, so do not want to waste it.
Threat Model
- The computer will be physically secure and will not be exposed to possible physical tampering.
- The only people who will have physical access to the computer will be authorized to use it.
- Physical theft will always be possible, but unlikely (low reward / high risk).
- The computer will be connected to the Internet. No servers will be running. Remote access will not be supported. Hardware and software firewalls will assist with security.
- Only the data stored on the computer needs to be encrypted. The names of the apps being used, timestamps of logins, system settings, app settings, MRU lists, shell history, etc. do not need to be encrypted.
Implementation approaches currently being considered (other ideas are welcome too):
- Put the system and data in a single partition and encrypt the entire partition with LUKS. This is the simplest method, but will likely not yield the best performance, as the system partition is needlessly encrypted (it doesn't seem needed given the threat model).
- Put the system in an unencrypted partition, and the data in a separate LUKS-encrypted partition. This will likely yield the best performance, but has the disadvantage of having separate pools of unused space in each partition, thus wasting storage space.
- Create a single partition, but use virtual volumes (e.g. using btrfs). Leave the system virtual volume unencrypted, and encrypt the data virtual volume with LUKS. After performing some internet searches, I'm unclear if this will actually work and how it will affect performance as compared to the implementation approach immediately above.