I would like to use AES-CTR to encrypt the same plaintext with the same key more than once (on different machines). I'm wondering whether I should try to use the same IV each time, or whether it's safe to use a random IV for different instances of the same plaintext. Using the same IV would require a deterministic method for IV selection, which poses its own problems.

I've seen very good explanations of why one shouldn't re-use a key/IV pair when encrypting different plaintexts using AES in CTR mode. (https://crypto.stackexchange.com/a/2993/83956)

I'm wondering whether encrypting the same plaintext twice with the same key but a different IV opens you to a similar attack. As I understand it, this would provide an attacker with

$C_1 = P \oplus F(K, IV_1)$

$C_2 = P \oplus F(K, IV_2)$

...which means:

$C_1 \oplus C_2 = F(K, IV_1) \oplus F(K, IV_2)$

...which doesn't look useful to me, but that depends on $F$ which I'm not familiar with.

Context: I have a system which requires a password and secret key together in order to log in. In a web client, I would like to save the secret key in local storage for convenience. I understand it is bad practice to leave secrets unencrypted in local storage, so I'm encrypting it with AES-CTR using a key generated from the user's password. The encrypted key will never be transmitted—only decrypted using the password for login purposes. They key is compressed before encryption, so any guesses at the password cannot be validated by attempting to decrypt the secret key. All guesses produce valid-looking secret keys, so an attacker would still have to use actual login attempts to brute force anything.

  • $\begingroup$ That will leak that you used the same IV and key combination and the same message is sent. I wonder how you keep that you are sending the same message again and get the previous key and IV to re encrypt it. Doesn't your system have some key renewals? $\endgroup$
    – kelalaka
    Commented Oct 2, 2020 at 10:54
  • $\begingroup$ You may want to consider using authenticated encryption (e.g. AES-GCM) for the encryption to (cryptographically) ensure that the secret key has not been altered somehow. $\endgroup$
    – SEJPM
    Commented Oct 2, 2020 at 11:12
  • $\begingroup$ Thanks @kelalaka, I've added some context explaining why I think it's ok for the cipher text to repeat. $\endgroup$ Commented Oct 2, 2020 at 11:12
  • $\begingroup$ @SEJPM I considered this, but that would mean that the encrypted secret key can be used to validate guesses against the password locally. And even worse, a correct guess rewards the attacker with the secret key! $\endgroup$ Commented Oct 2, 2020 at 11:13

1 Answer 1


I'm wondering whether I should try to use the same IV each time,

No. Using the same IV twice for the same message means that you leak that you sent the same message. If your set of messages is somewhat small this allows an adversary to more easily correlate reactions to messages with possible message contents.

whether it's safe to use a random IV for different instances of the same plaintext.

Yes, it is. The security definition which CTR satisfies (CPA security) very much considers the fact that the same message is sent twice. This will not leak anything (within reasonable bounds). To see this note that $F$ is usually modelled as a PRF, that is if your adversary doesn't know the key it might as well be a truly random function $f$ which takes its input, draws a response uniformly at random and stores the mapping for this input. This means that $F(K,I_1)$ can be translated to $f(I_1)$ which can be translated to the random string $R_1$ and the same can be done to construct $R_2$. Then if you look at $C_1=P\oplus R_1$ and $C_2=P\oplus R_2$ you will notice that both are "essentially encrypted with the one-time-pad", i.e. independent and uniformly random keys of size equal to the message length which will obviously not leak any information.

  • $\begingroup$ Thanks! The way you've explained it makes the answer seem obvious. $\endgroup$ Commented Oct 7, 2020 at 11:19

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.