10
$\begingroup$

I heard that key/IV pairs must not be reused in AES-CTR, or when using any stream cipher for that matter. Yet the attacks described do not seem to apply to AES-CBC.

Is reusing the same key several times dangerous in AES-CBC mode? Does the use of a random IV preclude all possible attacks in such cases?

$\endgroup$
  • 3
    $\begingroup$ "keys must not be reused in AES-CTR" This claim is wrong. Keys can be safely reused in CTR mode, as long as the probability that the counter ranges intersect is negligible. $\endgroup$ – Maeher Sep 22 '13 at 5:52
  • 1
    $\begingroup$ To clarify @Maeher's point, the problem is re-use of the same IV with a given key. Reusing the same key with AES-CBC is not necessarily problematic, but reusing the same key with the same nonce is. As a side note, if at all possible you should be using an authenticated encryption mode like AES-GCM. $\endgroup$ – Stephen Touset Sep 22 '13 at 7:19
10
$\begingroup$

Key/IV pairs should not be reused for either AES-CTR and AES-CBC - or for any other symmetric cipher for that matter. As a cipher is a Pseudo Random Permutation (PRP) inserting the same input will result in identical output. If a key/IV pair is reused then information is leaked to an attacker; the attacker can distinguish data with the same contents.

CTR is a streaming mode for block ciphers. In AES-CTR the key stream depends only on the key and the IV, not the plaintext. This key stream is XOR-red with the plaintext. It is possible to find additional information about the plaintext in addition to the issue above; if the key and a counter value are reused then the XOR of two ciphertexts is identical to the XOR of the plaintexts. So the key would still be safe, but the plaintext can be easily retrieved.

Reusing the key for any cipher should be no issue as long as the IV is unique - up to the specified amount of plaintext that the cipher can handle, usually a very large amount. In the case of CTR the IV should be unique enough to make sure that the counter does not repeat. Please read into CTR mode to see what that means when generating an IV. Make sure that it is understood what IV/nonce means for the specific application of CTR; the terms can be mixed up and may be used differently for specific protocols and implementations.

For CBC there are additional constraints: information about the IV should not be available in advance to an attacker that can alter the plaintext (chosen plaintext attack or CPA). Using a 16 byte value that is indistinguishable from random to an attacker should indeed preclude any attacks on the block cipher mode. That IV may simply be prefixed to the ciphertext in plain. If an authentication tag is used over the ciphertext then the IV must however be included in the calculation of the authentication tag (e.g. HMAC value).

$\endgroup$
  • 5
    $\begingroup$ I think a quick way to summarize this is: reusing a key/IV with CBC is bad. Reusing a key/nonce with CTR is catastrophic. $\endgroup$ – Jeffrey Goldberg Sep 24 '13 at 6:40
  • 2
    $\begingroup$ Note that CBC nor CTR provide protection of integrity or authenticity of the ciphertext (and thus plaintext). Certainly for transport security an authentication tag would be required and authenticated modes of operation such as GCM or EAX mode should be considered instead of (just) CTR or CBC. $\endgroup$ – Maarten Bodewes Feb 22 '17 at 1:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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