# IND-CPA security of mode of operation using triple AES with plaintext || IV+counter

I have found this figure of a mode of operation using a triple AES with m||IV+ctr input:

I suppose it's a custom mode of operation since I haven't seen it anywhere else. My question is if it is IND-CPA, and how to prove it in an adversarial model?

• I don't really understand your first sentence. If you could make it a little clearer. I'm studying for Cryptography exam and this is from an older exam. So I guess it doesn't qualify as homework. Commented Feb 10, 2020 at 18:16
• Hint: Are any two blocks possibly equal? Does this tell you anything about the ciphertext given that AES is a PRP? Commented Feb 10, 2020 at 18:18
• The adversary will send to the challenger m0, m1 where m0!=m1 and |m0|=|m1|. Since AES is IND-CPA, I don't see which set of m0, m1 would lead to any information about which one was encrypted by the challenger. I suppose the IV is chosen at random and used in one-time fashion by the challenger. Am I thinking something wrong? Commented Feb 10, 2020 at 18:32
• Commented Feb 10, 2020 at 19:17
• I am pretty sure it is NOT IND-CPA, it looks trivial to select a plaintext where sequential encryptions with different IVs lead to duplicate blocks Commented Feb 11, 2020 at 2:10

Seems to me that if you just look at the first layer that uses K1 that you can already show that it is CPA secure. After all, if the IV is always unique then $$M_n \| IV + n - 1$$ is always unique in this scheme. So then the input to the $$\text{AES}_{K_1}$$ block cipher is also unique. This makes the scheme have the same properties as the key stream of Counter Mode, with $$IV + n - 1$$ is the counter.

So unless $$K_1$$ is reused within the scheme, the scheme must be secure - regardless of any other encryption operations.

Now one thing to notice with the above reasoning is that I've proved it to be secure given key $$K_1$$. If you expect it to have a security of the 3 keys together (e.g. 128 x 3 = 384 bits for AES-128) then you may need to read up on meet in the middle attacks. At most the security will be 256 bits - that is if we don't put any constraints on memory usage. That's a separate security issue than IND-CPA though.

Of course, when it comes to practicality, this is one of the worst schemes you can think of. The number of key bits and operations is tripled to achieve additional security of about two times specified. More importantly, you'd also need more encryption operations as the IV takes away message space from each message block. The ciphertext also expands with the same factor.

• Hmm, I have the feeling I've answered this question before somewhere. Commented Feb 10, 2020 at 22:03
• If the IV was not handled properly, is there a pair m0, m1 to prove this to not be IND-CPA? I know about meet-in-the-middle attack, but if I have understood correctly, this isn't related to IND-CPA, they are two different security properties, right? Commented Feb 10, 2020 at 22:48
• 1. yes, of course. Just make m0 = m1 (perfectly allowed for CPA) and make sure that the IV repeats as well. In that case the ciphertext blocks are identical and you leak information that the plaintext blocks are identical. Obviously that more than breaks CPA as the ciphertext indistinguishably is should not be affected by the chosen plaintext attack. 2. Yes, different security properties, only the first two sections matter. I'll add a line. Commented Feb 10, 2020 at 23:14