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.