I was wondering if changing the cipher mode to AES-XTS in EncFS would be a sound idea. EncFS uses AES in CBC mode until the last 1KB block, and CFB mode for the last block if
len(block) < 1KB. This ensures that
len(plaintext) == len(ciphertext).
The design seems somewhat convoluted, but understandable considering those decisions were (probably?) made before any relevant standard was published.
My main concern is that AES-XTS seems to have been designed for data stored in block devices and not for a "user-space encrypting filesystem". In an encrypted user-space filesystem, each file would be a "block device" and each "block device" would use the same keys.
Apart from the obvious issue that encrypting the same file twice would result in identical ciphertexts (if not using per-file keys), how could we attack this design? :)
EncFS' default options
EncFS has several options when creating a volume. By default, files are encrypted using unique, unpredictable ivs; blocks are not authenticated (a per-block MAC option exists, but is disabled due to efficiency considerations); a "block" in EncFS defaults to 1024 bytes.
Why would anyone want to disable per-file ivs?
Disabling per-file ivs in EncFS raises several potential issues:
- Watermarking attacks
- Copy-paste attacks using blocks from different files
- Since the last block may be encrypted with a stream cipher, the keystream may be reused. Or not, since some magic shuffle operations are used.
- Additional information leaks
However, many people use EncFS with cloud-based storage solutions, such as Dropbox and Google Drive. Some commercial services exist there are/were based on EncFS, even disabling per-file IVs. I am not affiliated in any way with such companies.
When per-file ivs are disabled, data deduplication inside a specific volume will work very well. Identical plaintext on the same block offset will have identical ciphertext. From a bandwidth/space efficiency standpoint, this is a very desirable property. From a security standpoint, it is not.
So the question could be rephrased as: is using AES-XTS (which is less malleable than AES-CBC and more easily parallelizable, but it can leak more info since it does not chain) without per-file keys an acceptable security tradeoff, if trying to optimize a volume for a cloud storage service? Would enabling such a design be acceptable?