an attack against SSH2 protocol

[Wei Dai <weidai%eskimo.com@localhost>]

[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

-- 
http://cryptopp.com - free C++ cryptography and compression library