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?
AES256(key, NONCE) XOR Plaintext
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.