Is AES-XTS considered safe to encrypt multiple files with the same keys?

Question

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? :)

Thank you.

Additional clarifications/motivation

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?

Answer 1

From a draft of the IEEE spec,

"An XTS-AES key shall not be associated with more than one key scope. The reason is that encrypting more than one block with the same key and the same index introduces security vulnerabilities that might potentially be used in an attack on the system. In particular, key reuse enables trivial cut-and-paste attacks."

You are seriously breaking the warranty here. I take it you know this...

"The proof from Rogaway yields strong security guarantee as long as the same key is not used to encrypt much more than a terabyte of data (which gives q=236 blocks). For this case, no attack can succeed with probability better than 2^53 (i.e., approximately one in eight quadrillion). This security guarantee deteriorates as more data is encrypted under the same key. For example, when using the same key for a petabyte of data, attacks such as in D.4.2 have success probability of at most approximately 2^37 (i.e., approximately eight in a trillion), and with exabyte, of data the success probability is at most approximately 2^17 (i.e., approximately eight in a million). The decision on the maximum amount of data to be encrypted with a single key should take into account the above calculations together with the practical implication of the described attack, (e.g. ability of the attacker to modify plaintext of a specific block, where the position of this block may not be under attacker’s control)."

So you may have some space before the tradeoff becomes completely broken I guess.

Also, if the cloud storage system can prevent anything from being written to the user's space without first encrypting it, (or prevent anything from being decrypted that it didn't itself encrypt), then it might be able to prevent some copy/paste attacks (from users). Since all encryption/decryption/writes are done remotely from the attacking user, it eliminates some of the IEEE worries about some types of passive attacks and random data attacks.

Ok, that's my most generous answer. You're asking a question of the form, "There's this security standard. Can I throw out a major piece of it and make it useful for something else?"

And while it's super tempting to launch into comparative cryptanalysis of AES-CBC and AES-XTS with your modifications, the only responsible answer to all such questions has to be, "No, that will give you something that's broken and unverified, equivalent to just making something up from scratch. You shouldn't want that. The first rule of crypto is don't build your own crypto."

I highly recommended approaching this from scratch as, "I want a mode or protocol that accomplishes X, Y, and Z, but I don't care about attacks A, B, or C. Is there any such mode? If not, what gets closest?" Maybe there isn't, and you have to face the hard choice of deduplication or security. But hey, who knows, you might find that there's something you hadn't even considered that meets your design objectives.

Best of luck!