# How to defend AES against chosen-plaintext attack?

I have a server which encrypts files with the same AES key. Users can upload a file and download its encrypted version. A user can upload as many files as he wants. Users can decrypt the documents via the server after a D date. A user may see an other user's encrypted document, but it would be a disaster if he could decrypt it before the D date!

I've read in other stack overflow post that using the same initialization vector can make chosen-plaintext attack easy. So I want to generate a different initialization vector for every uploaded file. Is it a standard secure way to add this IV to the encrypted document?

My first idea is that I encrypt it with a different AES key and simply concat it to the encrypted byte array. But I'd rather use a more standard solution for this problem.

• Why are you using the same AES key? More details about your situation and restrictions would help. – Thomas M. DuBuisson Jan 20 '17 at 21:46
• I've removed the Java part from your question. It's not required for protocol design nor is it on topic here. – Maarten Bodewes Jan 20 '17 at 22:51

### TL;DR: AES is safe against plain-text attacks.

If :

• you do not reuse your IV
• you use a correct mode of operation (not ECB...)

Then you are safe against such attacks (you need at least these 3 conditions to be met).

On a side note, IV can be public, it is not a problem.

If you look at pretty much any of the many file encryption tools they are usually a hybrid system such as:

1. Generate a new random key, $k$.
2. Encrypt $k$ using some public key $p$: $w = Asymm_p(k)$
3. Encrypt the message, $m$, using $k$ and a symmetric algorithm: $c = E_k(m)$.
4. Throw away $k$ and $m$. Publish/send $c$ and perhaps $w$ depending on the situation.

This doesn't provide much, but it should provide confidentiality. When the date arrives the holder of the private key can decrypt $w$ and publish $k$.

• Given AES security, and considering a decent IV (no reuse), IND-CPA is guaranteed. So no need to consider an asymmetric scheme such as this one. It make things more complex uselessly, thus more risk of mistakes... – Biv Jan 20 '17 at 22:06
• @Biv This very much depends on how many encryptions and how much data is encrypted in the lifetime of his one key. This is why I asked my comment-question. – Thomas M. DuBuisson Jan 20 '17 at 22:14
• Assuming a 256 bit key you are pretty safe. ;) – Biv Jan 20 '17 at 22:14
• @Biv No you aren't. The issue here is IV collision not key collision. – Thomas M. DuBuisson Jan 20 '17 at 22:16
• Then I guess you have a birthday after ... 2^64 encryptions. – Biv Jan 20 '17 at 22:20