# Why does CTR mode XOR the plaintext into the output of the block cipher rather than XORing the plaintext into the input of the block cipher?

As I understand it, CTR mode essentially turns a block cipher into a stream cipher like so:

        _______________
|       |       |
| nonce |   i   |
|_______|_______|
|
_______V_______
|               |
|  block cipher |
key -->|  (encryption) |
|_______________|
|
V
plaintext --->(+)---> ciphertext


But by turning it to a stream cipher, one must be very careful not to reuse a nonce. It seems like it would be safer to do it like this:

        _______________
|       |       |
| nonce |   i   |
|_______|_______|
|
plaintext --->(+)
|
_______V_______
|               |
|  block cipher |
key -->|  (encryption) |
|_______________|
|
\---> ciphertext


While it still would be unwise to reuse a nonce, it seems like the effects would be less devastating if it were misused in this way. I see one main disadvantage, and that's that with the first formulation, only the encryption part of the block cipher need to be implemented, whereas with this second formulation, both encryption and decryption need to be implemented.

My questions are:

1. Does this latter mode of operation have a name?
2. Are there any obvious weaknesses in this latter mode?
3. Are there any other reasons why CTR is defined the first way?
• In your design, if the plaintext follows a pattern similar to the block counter, the block cipher inputs may repeat, exposing information about the plaintext – Richie Frame Mar 4 '14 at 10:13
• there is also the issue of known plaintext attack, which would apply even if the keystream was a true one-time-pad. i xor two messages together and xor with ciphertext believed to be one of them to replace the ciphertext. the problem with a true stream is that the data started before the first block you got and comes to an end after the last block you got. so there is not hash that you can compute. it appears that you get stuck framing the stream and requiring ranges to pull an entire frame - which may not have enough data to complete yet. ie: an encrypted radio station. – Rob Jul 8 '16 at 3:56

1. There are some serious problems with this design that would preclude it from being standardized, so it probably does not have a name.

2. The 2 visibly main flaws are as follows:

• If the plaintext follows a pattern similar to the block counter, the block cipher inputs may repeat, exposing information about the plaintext (exact same issue as reuse of nonce, but could happen multiple times per message, example given at end)

• Plaintexts with a length not equal to a multiple of the block size would need the length included with the ciphertext in order to decrypt, as the full block output is required to decrypt, or they require padding of the last block.

3. The structure of CTR has several desirable properties that your example does not. It allows encryption without padding or additional length data to decrypt. It allows precomputation of the cipherstream prior to the plaintext being available, which can mean huge speed improvements if there is enough memory available and message plaintext is available at irregular intervals. CTR can also be processed in a highly parallel manner, and requiring the plaintext as an input could slow that down if it is not available immediately.

Here is an example of a duplicate block:

"THIS IS A TEST SIMPLY TO EXPLORE WHAT WILL HAPPEN IF WE ENCRYPT THIS IS A TEST WITHOUT A SECURE MODE"

Block 0 plaintext = "THIS IS A TEST S", block 4 plaintext = "THIS IS A TEST W"

In this example, the input to the block cipher will be the same for block 0 and 4 for this message, regardless of the nonce, as "W" becomes "S" when xor'd with the block counter for block 4. Lots of data types have similar types of repeating information with only small changes, such as image files and executable programs. This is almost as bad as ECB for potential plaintext recovery.

• Great example with s->w! – figlesquidge Mar 4 '14 at 11:34
1. It probably doesn't.

2. Yes. For strings $x,m0,m1$ such that $\text {length}(x) = \text{length}(nonce)$ and $\text{length}(m0) = \text{length}(i) = \text{length}(m1)$
$( nonce || i ) \oplus ( x || m0 ) = ( nonce || j ) \oplus ( x || m1 ) \iff m0 \oplus m1 = i \oplus j$ .

3. I'm not aware of any.

• CTR is designed in this way as a technical equivalent of One TIme Pad where the full entropy random keystream is replaced by a pseudo random generator – Alexandre Yamajako Mar 4 '14 at 9:06
• Also it is designed that way so that the stream can be precomputed prior to the plaintext being available, which can save a crapload of computing time under the correct circumstances – Richie Frame Mar 4 '14 at 10:10