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 encrypting files using an AES-256 CBC cipher and an SHA-256 HMAC every 64KB in the file. Since AES CBC needs an amount of input bytes to be divisible by 16, I use PKCS#7 padding to bring the amount of bytes up to a count divisible by 16 at the end of the file.

For this and for most cases of cryptography, does knowledge of the original file size expose a weakness enabling an attacker to gain an advantage in decrypting the data? If someone had knowledge of the way an encryption system works, it may be feasible for them to guess the original file size. Is this a problem?

share|improve this question
As for the original question, standard cryptography assumptions make no effort to conceal the original file's size. It may be desirable to do so in some situations, and it can be done to some extent, but in your case it seems unwarranted. – Thomas May 9 '13 at 22:39
See Kerckhoff's principle; although I understand that not all cryptosystems are implemented this way, I believe that most use this as a basis. – JZeolla May 10 '13 at 12:23
up vote 3 down vote accepted

This seems like it may be an unnecessary complication. Why not encrypt the whole file at once, and HMAC the entire result? Or alternatively, use an encryption mode that has this built in, like AES-GCM?

But to answer your original question, no, it does not introduce any weaknesses. If it did, knowing the value to within 16 bytes wouldn't be much of a deterrent. There's even stream ciphers like AES in CTR mode that reveal exact message lengths.

share|improve this answer
His approach can make it safe to output plaintext blocks without reading the whole file. $\hspace{.6 in}$ – Ricky Demer May 9 '13 at 22:43
When I start receiving data, I'm not sure of its ultimate size. Therefore, I do a cumulative HMAC-SHA256 on each chunk just to be paranoid. It adds 16 bytes every $c$ bytes, where $c$ is the chunk size, so it's not the most efficient thing in the world, but it should work for my purposes. – Naftuli Tzvi Kay May 9 '13 at 22:54
Right, and I need to be able to check passphrase validity really quickly without having to read through an entire file of 16GB in length ;) – Naftuli Tzvi Kay May 9 '13 at 22:55

Yes, feasibility to guess the plain text size might be a serious vulnerability in real life scenarios. For instance, in traffic analysis the approximate length of the messages in a communication, might reveal enough information about what is communicated, for it to be possible to deduce the gist of it. If such threats exist in your case, however, you will probably have to consider more radical counter measures than just apply a few byes of PKCS#7 padding at the end of your file fragments.

share|improve this answer
Just wanted to comment that a great example of this is ARP. – JZeolla May 10 '13 at 12:22

Your Answer


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.