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?

Question

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?

Answer 1

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.

Answer 2

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.