[Posted to sci.crypt and the IETF SSH working group mailing list.]
Phil Rogaway observed that CBC mode is not secure against chosen-
plaintext attack if the IV is known or can be predicted by the attacker
before he choses his plaintext [1]. Similarly, CBC mode is not secure if
the attacker can observe the last ciphertext block before choosing the
next block of plaintext, because the last block of ciphertext
essentially serves as the IV for the rest of the message.
The attack itself is very simple. Remember that in CBC mode, each
plaintext block is XOR'ed with the last ciphertext block and then
encrypted to produce the next ciphertext block. Suppose the attacker
suspects that plaintext block P_i might be x, and wants to test whether
that's the case, he would choose the next plaintext block P_j to be x
XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j
XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his
guess by looking at whether C_j = C_i.
The SSH2 protocol, when used with a block cipher in CBC mode, does allow
the attacker to observe the last ciphertext block of a packet, which is
then used as the (implicit) IV of the next packet. SSH2 also multiplexes
multiple channels into one transport stream encrypted with a single key.
This gives the attacker who can input data into one channel a chance to
attack other channels. (Another possible attack scenario is a multi-user
chat session.) Fortunately, the attacker may not have complete freedom
to choose the first block of the plaintext of the next packet. For
example, the first 4 bytes of the plaintext of any packet consist of the
packet length. Assuming that the SSH2 application has a maximum packet
size of 2^16, the attacker is constrained to choosing a plaintext block
that begins with two zero octects. This implies that the attacker would
have to wait at least 2^16 packets on average before he has a chance to
perform this attack.
However even with this and other potential constraints it seems very
possible for the attacker to succeed in some situations. So I suggest
that the SSH2 protocol be fixed. The simplest way to do this would be to
deprecate the CBC mode block ciphers, and instead specify ciphers in
CFB, CTR or OFB mode. Currently, the only cipher defined in the SSH2
transport protocol draft that is not a block cipher in CBC mode is ARC4.
Until this fix is implemented, users of SSH2 applications may want to
consider switching to ARC4 for encryption.
[1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-
comments-00.txt