Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?
share|improve this question
    
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 at 10:13
add comment

2 Answers 2

up vote 11 down vote accepted
  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.

share|improve this answer
    
Great example with s->w! –  figlesquidge Mar 4 at 11:34
add comment
  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.

share|improve this answer
1  
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 at 9:06
1  
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 at 10:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.