[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