Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

It is my understanding that block ciphers like AES don't have any built-in mechanisms to verify data integrity upon decryption, although some modes of operation might provide that.

I played around with 7-zip, which uses AES-256/CBC. I encrypted a bunch of files and deliberately corrupted it zeroing a couple of bytes. I observed that, as expected, the earlier I zeroed the bytes, the more files would be corrupted.

I also noticed that supplying an incorrect password wouldn't stop decompression at all. Only after decompressing the entire archive, 7-zip would report the password might be wrong. Since it saves checksums of the files, it can tell if they're corrupted. This makes sense.

Now enter Adobe Acrobat X. I encrypted a PDF (AES-256 again). To my surprise, corrupting bytes in the encrypted file seemed to have no observable effect on the result. Note that Acrobat X encrypts metadata as well, and I edited something well beyond where I'd expect metadata to be anyways.

I was still able to see the read the whole file. I then removed the password from both the original and "corrupted" files and did byte by byte comparisons. I noticed that besides some address ranges where I presume metadata is stored (since they differ every time I decrypt the same file), there was only a single block where 16 bytes (coincidentally AES' block size) are different.

Acrobat also seems to be able to verify if a password is correct without attempting to decrypt anything, implying it has a hash of it (or something) stored somewhere.

  • Does it make sense to do that (verify a password or key is correct without attempting decryption)? Wouldn't that make it easier for an attacker to bruteforce the password?
  • Am I correct in guessing that Acrobat uses ECB? Is there an advantage to it?
  • How do AE modes behave when it comes to:
    • Verifying a key is correct before decryption is attempted
    • If a byte of ciphertext is corrupted accidentally, how does that affect what comes after it?
share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

If the encryption scheme uses CBC and you alter one bit of the encrypted data, then, upon decryption, this will have two effects: it will garble the corresponding block, and it will flip the corresponding bit in the next block (16 bytes further, with AES). It will not alter the rest of the data. This is quite unlike to what happens if you flip one bit of the clear data, when encrypting: that one would alter all the subsequent blocks, till the file end.

For other modes, things vary. Flipping one bit of encrypted data just flips the same bit of the clear data with OFB and CTR modes. With ECB, it alters one block exactly. With CFB, it will modify all subsequent blocks.

For the authenticated modes, CTR is often used internally (e.g. with EAX) but the point is moot because the integrity check will detect the alteration and report it (it is still up to the application to get rid of whatever it decrypted in that case).

Including an explicit password check is customary (e.g. OpenPGP does it) and it does not weaken the encryption, if done properly. Basically, the password must first be slow-hashed (with a salt), and then a hash of the resulting key is used as checksum. In any case, no sane attacker will decrypt the whole file for each password that he tries: he just decrypts the first two or three blocks, to see if he finds a realistic-looking file header. We cannot rely on decryption speed as a substitute for the slow hashing.

share|improve this answer
    
I see. I wonder why 7-zip reports corrupt data on all subsequent files if I corrupt the ciphertext corresponding to a single file (all of them being much larger than 16 bytes). –  quantumSoup Oct 17 '12 at 20:23
    
Normally, files in a Zip archive are compressed and encrypted separately, so that a file can be extracted without processing the whole archive. –  Thomas Pornin Oct 17 '12 at 20:35
    
It makes sense now. 7-zip compress files together to take advantage of possible similarities between files (something easily seen if you create multiple copies of a file and compress them all). I must have corrupted a part of the dictionary which was used by more than one file. –  quantumSoup Oct 17 '12 at 21:05
add comment

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.