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?