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.

This question already has an answer here:

I used AES256-CBC to SSH to a remote server. Recently, it stopped working with the following message:

no matching cipher found: client aes256-cbc server  
aes128-ctr,aes256-ctr,arcfour256,arcfour,3des-cbc

When I used AES256-CTR as a cipher to SSH to the server, it worked as expected.

I read this article which outlines the following:

CBC (Cipher-block chaining)
Encryption parallelizable: No
Decryption parallelizable: Yes

CTR (Counter)
Encryption parallelizable: Yes
Decryption parallelizable: Yes

Is “Encryption parallelization” necessary in SSH?

Any other advantages of AES256-CTR over AES256-CBC used in SSH except being more robust against padding oracle attacks?

share|improve this question

marked as duplicate by e-sushi, hunter, Dmitry Khovratovich, otus, poncho Aug 10 at 11:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
I'm fine with the dupe of course, mods please note that the other answer does not contain a list of differences / advantages, i.e. I would like my and Thor's answer preserved. –  owlstead Aug 10 at 18:00
    
@owlstead Thanks for noticing it. I read the other question before asking mine but did not found any answers to my question. So I asked this question and some people marked it as duplicate... I am fine with this: I got the answer to my question and now I use only (if supported) AES256-CTR in my SSH connections. –  Rlearner Aug 18 at 2:44

3 Answers 3

up vote 3 down vote accepted

Other advantages of CTR are:

  • easier to decrypt from a certain offset within the ciphertext
  • no randomness requirements for the nonce
    • nonce can be calculated, e.g. be a simple counter
    • nonce can be a message identifier
  • $E = D$: encryption is the same as decryption, which means
    • only encryption or decryption required from the block cipher
    • less logic required
  • no padding overhead or mechanism required
  • key stream can be pre-calculated (latency advantages)

Draws:

  • sequential speed the same (about the same number of ciphertext blocks)
  • cryptographic security (when used properly)

Disadvantages:

  • nonce reuse is catastrophic, confidentiality is completely lost
  • leaks somewhat more information about the size of the plaintext
  • multiple, slightly different schemes with regards to IV creation and the method that the nonce is used
  • still less common in libraries or known by (starting) developers

Another questionable disadvantage is that CTR has no error propagation, but that should probably be considered an advantage by now; if you want integrity, use an authentication tag (MAC or signature).


You can attack CBC and CTR using different methods, with different consequences. If CBC mode has problems in a certain protocol, then switching to another mode has its advantages of course. See the answer of Thor for good reason to switch to CTR for OpenSSH specifically.

That's probably a better reason to disable CBC than the reasons given above. If you want to know for sure, you should ask the OpenSSH developers though (or the person that disabled CBC-mode, anyway).

share|improve this answer
    
Less suitable to create a MAC out of could also be one, I guess. Then again, less susceptible to attacks from such a MAC... –  owlstead Aug 8 at 23:08

There seems to be an attack on SSH when using CBC: Plaintext Recovery Attacks Against SSH. I have just scanned the paper and they state, that this will not be possible when CTR mode is used. I don't think that en-/decryption parallelization is need or even utilized in SSH.

Update: Link to CERT concerning the topic: Vulnerability Note VU#958563 SSH CBC vulnerability

share|improve this answer
    
Would not parallelization speed up things when a multicore processor is used as mentioned @user1204481 ? –  Rlearner Aug 9 at 14:24
    
It would. But you would need to modify the en/decryption code to utilize multiple threads working on the same message in parallel. On server side, when we have a lot of parallel sessions, the added complexity would be useless. On client side I would also not add that complexity for a single subset of supported encryption modes. To much complexity for a secure shell protocol I would say. –  Thor Aug 9 at 14:36

Parallelization is not a necessity but it can help to speed things up if you have a multicore processor. This is because of the parallel nature of CTR mode where the blocks are encrypted independently of each other.

Another main advantage, besides being parallelizable, is that unlike CBC, CTR mode can perform certain calculations offline to prepare the key stream. When the PT/CTXT blocks are available, it simply XORs the PT/CTXT with the key stream online to generate CTXT/PT, decreasing the latency of the system.

share|improve this answer

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