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.

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

2 Answers 2


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

If :

  • you do not reuse your IV
  • your IV are random
  • 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.

Worth reading:


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$.

  • 1
    $\begingroup$ 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... $\endgroup$
    – Biv
    Commented Jan 20, 2017 at 22:06
  • $\begingroup$ @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. $\endgroup$ Commented Jan 20, 2017 at 22:14
  • $\begingroup$ Assuming a 256 bit key you are pretty safe. ;) $\endgroup$
    – Biv
    Commented Jan 20, 2017 at 22:14
  • $\begingroup$ @Biv No you aren't. The issue here is IV collision not key collision. $\endgroup$ Commented Jan 20, 2017 at 22:16
  • $\begingroup$ Then I guess you have a birthday after ... 2^64 encryptions. $\endgroup$
    – Biv
    Commented Jan 20, 2017 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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