Is AES-XTS considered safe to encrypt multiple files with the same keys? 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) &lt; 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?
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!