# Is regular CTR mode vulnerable to any attacks?

Regular plain CTR mode, is it vulnerable to any attack?

I plan to write a program to encrypt a drive with ctr mode. Would this be wise? Would AES be better?

When I look at this diagram, it looks pretty solid to me.

If the question is "too broad", allow me to rephrase:

Which is better, AES 256 or CTR mode like the picture above to encrypt a drive?

• – user991
Mar 20 '16 at 16:46
• You can't compare AES vs. CTR. You need a block cipher (like AES) to use CTR mode. They are not alternatives. Do you actually mean ECB vs CTR?
– otus
Mar 20 '16 at 17:58
• @tuang If they can change data, the attacker may be able to change it in his favor such that security policies get changed resulting in easier data exfiltration once the system is in use. XTS and EME are two modes of operation for AES that should deal with this better than CTR while not being much slower. Pure ECB is the worst possible choice.
– SEJPM
Mar 20 '16 at 18:48
• I don't know of any way to use AES without also using some block cipher mode of operation. AES256 is often used with CTR. So your question doesn't make sense to me, it's like asking "Which is better, a truck with a diesel engine or a truck with 4 wheels?", when most trucks have both. Did you maybe mean to ask "Which is better, XTS or CTR to encrypt a drive?"? Mar 20 '16 at 20:48
• The "CTR", as described in the Wikipedia: block cipher mode of operation article, is a mode of operation that is used with a block cipher, often AES. That CTR is not a cipher in itself. Are you maybe referring to some other CTR? Which one? Mar 21 '16 at 0:15

## 1 Answer

Summing up the discussion in the comments: What you are describing is the CTR Mode of operation of block ciphers, which requires an encryption function ("E" in your diagram) like AES. So, "should I use CTR or AES?" should instead be "should I use AES with CTR or with another mode?"

As @RickyDemers already mentioned, CTR mode (without any additional authentication step) is malleable, which means that it is possible to change the meaning of the ciphertext. For example: you want to encrypt the message $m=01010101$. Counter mode will use the counter and the encryption function to generate a keystream, for example $s=10010110$, and compute the ciphertext

$$c = m \oplus s = 01010101 \oplus 10010110 = 11000011$$

An attacker could now, for example, flip the second bit in the plaintext $m$ by changing $c$ to $c'$:

$$c' = c \oplus 01000000 = 10000011$$

The decryption would use CTR mode to derive the same key stream $s$ as before, but use it to decrypt $c'$, which would result in

$$m' = c' \oplus s = 10000011 \oplus 10010110 = 00010101$$

As you can see, the second bit (which used to be $1$) was changed to $0$ by this change, while leaving the remaining parts of the file data unchanged. This is called malleability.

You can prevent this by using a message authentication system like HMAC or, even better, an authenticated encryption mode like GCM, which functions like CTR mode but also authenticates the data and thereby makes it impossible to change the ciphertext without being detected. Many systems were broken because they did not use any authentication of the ciphertext, and more were broken because they did the authentication wrong.

So, my reply would be:

• Use AES with a sensible mode: XTS or EME if you want to authenticate your data separately using HMAC or something similar, or GCM if you want to do it all at once (I'm not sure if GCM is suitable for full disk encryption though, and be careful when using it, there are some ways to shoot yourself in the foot)
• Also, if this is to be more than an experiment on your part, seriously consider using an established disk encryption tool instead
• Use a cryptographic library instead of writing the encryption code yourself. There are many non-obvious ways to shoot yourself in the foot, and any one of them may be fatal to the security of your system. Established cryptographic libraries have been vetted for these bugs and while they do crop up occasionally, they are much less likely than in any code a single person can write.
• Read and understand this question and all answers in its entirety.
• Your misconception about AES and CTR mode indicates that you are pretty new to the field of cryptography. That's fine, everyone was a novice at some point! But make sure to understand the field a little more before building anything serious, because bugs in cryptography are both hard to find and can be devastating if they occur in software used in practise.
• Thank you, @malexmave for the nice answer! It really cleared things up Mar 21 '16 at 19:09
• You're the type of person that makes this stackexchange site great. I'll try to learn more before implimenting anything into any software Mar 21 '16 at 19:10
• Additionally, CTR with a reused IV is completely broken, complicating its use in full-disk encryption scenarios. Use a mode designed for FDE uses like XTS, as suggested. Apr 27 '16 at 18:00