18

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?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Rlearner
  • 283
  • 1
  • 2
  • 4
  • 2
    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. – Maarten Bodewes Aug 10 '14 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 '14 at 02:44

3 Answers3

11

Here are some other advantages other than being impervious to padding oracle attacks:

  • 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)
  • parallel computation of the key stream is also possible

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
  • possible to perform one or more bit flips in the plaintext by the attacker (also affects plaintext oracle attacks)
  • 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).

Beware that AES-CTR is still vulnerable to plaintext oracle attacks. Padding oracle attacks are only a subset of plaintext oracle attacks. If the system returns specific errors if the ciphertext is altered then an adversary can still learn information about the plaintext. CTR actually makes this easier since it allows the attacker to flip any bit of the plaintext; if CBC is used then a whole block of plaintext gets randomized.

Then again, AES-CTR is the underlying cipher of all of the popular AEAD modes for AES. So if you want to add message integrity / authenticity then AES-GCM is only one step away.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
8

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

Thor
  • 768
  • 3
  • 6
  • Would not parallelization speed up things when a multicore processor is used as mentioned @user1204481 ? – Rlearner Aug 09 '14 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 09 '14 at 14:36
0

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.

BlaX
  • 736
  • 7
  • 18