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$ – Thomas M. DuBuisson Jan 20 '17 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 Jan 20 '17 at 22:51

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

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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