winnielinnie
MVP
- Joined
- Oct 22, 2019
- Messages
- 3,579
Be mindful not to use names for datasets and snapshots that are "interesting", since native ZFS encryption does not obfuscate metadata and pool structure. Here is a comparison between common block encryption solutions:
Native ZFS, at rest (or powered off):
LUKS, at rest (or powered off):
VeraCrypt container, at rest (or powered off):
[1] Seems like native ZFS encryption is "leakier" than I first suspected, but it makes sense considering it requires certain information and metadata in order to send and recv, create snapshots, scrub, etc, without requiring encrypted datasets to be unlocked.
[2] Until decrypted, a VeraCrypt partition/device appears to consist of nothing more than random data (it does not contain any kind of "signature"). Therefore, it should be impossible to prove that a partition or a device is a VeraCrypt volume or that it has been encrypted.
There is a caveat concerning native ZFS encryption vs traditional block device encryption: what is exposed to the public. I'll give my own summary understanding comparing three common options:My goal is just to not need to worry about what's on the disk if I need to send it in for warranty replacement or when I retire it.
Native ZFS, at rest (or powered off):
- Inaccessible
- File Data
- File Names and Properties
- Sizes of individual files (unsure about this one)
- Directory listings and structures
- Logs (if logs are saved here)
- Accessible
- Encryption Options and Hashes
- ZFS Metadata and Options
- Number of Files and Blocks (via pointers and inodes) [1]
- Dataset Names
- Snapshot Names
- Free Space
- Used Space
LUKS, at rest (or powered off):
- Inaccessible
- File Data
- File Names and Properties
- Directory listings and structures
- Sizes of individual files and folders
- Number of files and folders
- Logs (if logs are saved here)
- Free Space (can be inferred if underlying devices were not filled with random data prior to creation)
- Used Space (can be inferred if underlying devices were not filled with random data prior to creation)
- File System and metadata within
- Accessible
- Encryption Options and Hashes
VeraCrypt container, at rest (or powered off):
- Inaccessible
- File Data
- File Names and Properties
- Directory listings and structures
- Sizes of individual files and folders
- Number of files and folders
- Logs (if logs are saved here)
- Free Space (container filled with random data upon creation)
- Used Space (container filled with random data upon creation)
- File System and metadata within
- Encryption Options and Hashes
- Accessible
- Apparently nothing, just a suspicious mess of random data [2]
[1] Seems like native ZFS encryption is "leakier" than I first suspected, but it makes sense considering it requires certain information and metadata in order to send and recv, create snapshots, scrub, etc, without requiring encrypted datasets to be unlocked.
[2] Until decrypted, a VeraCrypt partition/device appears to consist of nothing more than random data (it does not contain any kind of "signature"). Therefore, it should be impossible to prove that a partition or a device is a VeraCrypt volume or that it has been encrypted.