Imagine I have a file encrypted using AES CBC mode with a key and a random IV. The attacker access to the encrypted text and the IV used but not the key.

In this scenario there is no vulnerability since the IV is random.

Now lets assume the attacker gets information about the plaintext used. The plaintext is a survey form filled out by a user. So there is a fixed format for the data encrypted. In that case if we assume the attacker has access to the empty survey form (with the questions) does that change the presumed security of the encrypted data? The random IV does not matter any more. The situation lends itself to a chosen plaintext attack. Am I missing something here?

How do you protect the data in this case?

EDIT: The key is randomly generated and stored in a database completely separated from the encrypted data.

  • Where does they key come from? It's likely the weakest part and you left that "detail" out. May 23, 2014 at 17:45
  • Please see the edit. I added info about the key.
    – user220201
    May 23, 2014 at 18:09
  • 2
    The only bad thing I can see is that the size of the filled survey is leaked, which can give some insight on the extent of its completion. Nothing padding can't fix. May 23, 2014 at 18:14
  • "In this scenario there is no vulnerability since the IV is random." There are many more classes of vulnerabilities besides IV reuse... May 23, 2014 at 21:22

2 Answers 2


The whole point of symmetric encryption is that if an attacker doesn't have the key, they can't decrypt the data. AES has no publicly-known computationally feasible attacks (significantly better than brute-forcing the entire 2128 key space) on it that are relevant to this scenario.

If the data is at rest, there's no chosen plaintext attack -- there's no system that accepts chosen plaintext and encrypts it. You can only do the chosen plaintext attack if an attacker can submit arbitrary plaintexts to a system that will encrypt them and spit back the ciphertext.

Now if you expanded the attack surface to one where an attacker could request a plaintext be encrypted with an unknown key, then there is a potential chosen plaintext attack if the IV is reused or known to the attacker prior to submitting their plaintext.

With the expanded attack surface, then if (1) the IV was fixed or known to the attacker prior to submitting the plaintext, and (2) an attacker could convince your system (that has the key) to encrypt arbitrary text submitted by them, and (3) the message space for each block is fairly small (only say a few thousand/million/billion possibilities which is significantly smaller than the full 2128 options allowed with 16 arbitrary bytes) for each 16-byte block of plaintext), then yes attacker efficiently could submit arbitrary plaintext with the same fixed IV (or account for the changing IV when making their plaintext guess) until they found a match to each block of the ciphertext they wish to decrypt. They could do this block by block (an AES block is 128-bits = 16 bytes) to sequentially guess the original plaintext by brute-force (of the small message space).

However with a random 128-bit IV not known ahead of time, this attack would not work. Why? Because in CBC mode c[0] = E(k, p[0] XOR IV), c[i] = E(k, p[i] XOR c[i-1]) for i > 0 and the IV changes every time (and is unknown when you submit the plaintext, so you can't account for the change in IV and your change in your guess of p[0]).

How do you protect the data in this case?

The data is already protected.


The data is protected. The attacker can't decrypt its contents, not even with the (partial) plaintext (otherwise we would be talking of AES as a broken cipher).

However, you also need to protect the integrity.

For example suppose that the survey contains some Yes/No questions and we were encrypting in CTR mode. If Eve has access to the answers to the survey given by other employees, she could blindly change the answers of someone she hates to make them look bad (eg. imagine that a quesiton was «Are you a terrorist?»).

Using CBC makes the attack harder, as the next block would be corrupted, but I wouldn't discard it. A solution would be to save a hash at the end and verify that it matches the decrypted message.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .