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 --&gt;|  (encryption) |
       |_______________|
               |
               V
plaintext ---&gt;(+)---&gt; 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 ---&gt;(+)
               |
        _______V_______
       |               |
       |  block cipher |
key --&gt;|  (encryption) |
       |_______________|
               |
               \---&gt; 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:


Does this latter mode of operation have a name?
Are there any obvious weaknesses in this latter mode?
Are there any other reasons why CTR is defined the first way?
There are some serious problems with this design that would preclude it from being standardized, so it probably does not have a name.
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.

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.