16
$\begingroup$

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?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ 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. $\endgroup$ – Maarten Bodewes♦ Aug 10 '14 at 18:00
  • $\begingroup$ @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. $\endgroup$ – Rlearner Aug 18 '14 at 2:44
9
$\begingroup$

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).

Improve this answer
$\endgroup$
1
  • $\begingroup$ Less suitable to create a MAC out of could also be one, I guess. Then again, less susceptible to attacks from such a MAC... $\endgroup$ – Maarten Bodewes♦ Aug 8 '14 at 23:08
8
$\begingroup$

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

Improve this answer
$\endgroup$
2
  • $\begingroup$ Would not parallelization speed up things when a multicore processor is used as mentioned @user1204481 ? $\endgroup$ – Rlearner Aug 9 '14 at 14:24
  • $\begingroup$ 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. $\endgroup$ – Thor Aug 9 '14 at 14:36
0
$\begingroup$

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.

Improve this answer
$\endgroup$

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