Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking to do file encryption of a bunch of individual files, some small, some quite large. The files will be write-once/read-many, so I could use CBC, however, since the read-access needs to have seekability, XTS seems a better fit. One issue, as I understand it, is that XTS (or CBC for that matter) is malleable... i.e. if the encrypted cipher text is modified, an attacker could potentially do some targeted things to files. So I was thinking surely this problem is already solved but it wasn't clear to me what the standard was, if any. Performance is a concern, so one thought I had was simply running a CRC on each XTS sector and including the CRC result in the plaintext for encryption of that XTS sector (e.g. just expand each sector by the 4 octets). Thus, if anything in the sector was modified by an attacker, the decrypt would fail (i.e. the CRC wouldn't likely match). Is there a smarter way, or a standard that's "fast"?

EDIT: it occurs to me that if the files are rewritable (which currently they are not) a CRC on each cluster in XTS mode is still open to an attack where an attacker can guess at the plaintext and write a cluster to a known location in the file and see if it matches the cluster that's already there. Only way to prevent that is to have a random IV per block as well, that changes per write, I think.

share|improve this question
Actually, XTS is not what is normally named "malleable". You can change a ciphertext block and the corresponding plaintext block will change too, but the result of this change is not predictable by the attacker without knowing the key. For CBC, changing a ciphertext block will change the corresponding plaintext block in a unpredictable way and the next plaintext block in a predictable way. – Paŭlo Ebermann Jun 25 '13 at 15:12
You should use a MAC, not a CRC (which is not a cryptographic operation), and preferably on the ciphertext, not the plaintext. – Paŭlo Ebermann Jun 25 '13 at 15:13
Thanks for the comments... it was my impression that a MAC operation would be high-cost; CRC is low(er) cost, but provides no protection unless it too is protected. But to your point about malleability... perhaps MAC or CRC isn't really needed at all and it's fine how it is? – mark Jun 25 '13 at 16:05
Quite likely calculating a MAC is cheaper than the IO-operations to write the block. I'm not sure if there is any cryptanalysis of an encrypted CRC, I suppose this also depends on the mode of operation. In CBC mode you can change the first block arbitrarily by manipulating the IV. Use a MAC (which should include the IV, by the way, and everything else which might relevant to the encryption) and you are on the safe side. – Paŭlo Ebermann Jun 25 '13 at 19:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.