# Is there any real attack deployed on the CTR mode over history?

The CTR mode, with its CPA security, is one of the malleable block cipher mode of operations. An attacker can simply modify the bits of the ciphertext stream in their advance. This is due to the lack of integrity and that can be easily prevented with an HMAC. With Encrypt-then-MAC $$(c,IV) = \operatorname{AES-CTR}(IV,message)$$ and $$tag = \operatorname{HMAC-SHA256}(key,IV\mathbin\|c)$$

We have seen lots of real examples on the CBC mode due to the padding oracle attacks over the years. Padding oracle attack, however, is not applicable to CTR mode since it doesn't require any padding at all.

• Is there any real attack deployed on the CTR mode over history?*

*Note: This question come into my mind while answering this question; Disadvantages of AES-CTR?

• attacks on the mode would probably be on subset of implementations that lack authentication, I would hope that any of those would be considered implementation mistakes – Richie Frame Oct 16 '20 at 19:07
• @RichieFrame yes indeed, it would be a lack of authentication or ignoring the incorrect tag due to the bad/illiterate coding. – kelalaka Oct 16 '20 at 19:12
• CTR nonce reuse is a thing that happens. As is choosing the nonce to be incrementing counter in a way that causes partial keystream reuse between messages. – Jack Lloyd Oct 18 '20 at 13:48
• @JackLloyd Yes, and it is known from the beginning. What we are looking for here is a real attack case like done padding oracle attacks in TSL over the year. – kelalaka Oct 18 '20 at 15:10
• I'm not sure what you mean by "real attack case"? I have found both of these bugs in commercial cryptographic software during reviews. If you are looking for a public example I believe Tarsnap had a repeated CTR nonce bug. – Jack Lloyd Oct 21 '20 at 23:04