# Repeated NONCE in CTR mode

My understanding is that, in CTR mode, the NONCE must be unique because, if a NONCE is reused, multiple plaintexts will be XORed with the same value and this gives an attacker leverage to decrypt the data.

If you have a situation where it is hard to guarantee that the NONCE will always be unique, but you have a fast (whatever that means in your context) encryption implementation, can I take away the leverage that repeated NONCES give by adding an additional encryption step the normal CTR mode process?

E.g. replace

AES256(key, NONCE) XOR Plaintext


with

AES256(key2, (AES(key1, NONCE) XOR Plaintext))


I understand I loose CTR mode's ability to work with arbitrary length plaintexts (which is fine for me, I'm happy working in blocks), and that I have doubled the amount of encryption I need to do, but I think this retains the advantages of CTR mode (as opposed to ECB mode) while gaining some protection against repeated NONCEs.

Is this approach valid? Is there a lighter way to gain some protection against repeated NONCEs?

I am focusing on CTR mode because my communication channel is not necessarily reliable and I worry about the need to "resync" if I use any of the chained modes.

• The proper way to resync is creating small independently encrypted (and authenticated) messages with distinct nonces. – CodesInChaos Aug 24 '16 at 7:11
• still vulnerable to the chosen plaintext attack - if nonces collide, the encryption is deterministic. – kludg Aug 24 '16 at 7:36

Suppose you use the same IV for two messages $m_0||m_1||...m_n$ and $m_0'||m_1'||...m_n'$ where all the $m_i$ are 128-bit blocks. Each block is XORed with the same keystream value as the corresponding block in the other message. They then pass through AES, the same as in ECB mode. If any $m_i=m_i'$, they have the same ciphertext, so the cipher leaks information about the message.