Re: an attack against SSH2 protocol

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

So, I'm surprised to see no technical comments on this so far, either
here or on my local view of sci.crypt.

The attack appears to be extremely narrow -- to restate it
(please correct me if i'm wrong)
 - real-time adaptive chosen plaintext attack
 - attacker can verify a guess at one block of plaintext occurring 
immediately before the injected plaintext
 - the chosen plaintext is chosen based on the ciphertext of the
 guessed plaintext. 

I do have to question the arcfour/RC4 recommendation, though -- as
currently specified, ssh is vulnerable to the RC4 "weak key" problem
because, as specified, it doesn't discard the start of the keystream.
(fixing this has been discussed, but there seemed to be very little
interest in doing work on RC4/arcfour when this was last raised).

Moreover, it appears to be fairly straightforward to make an
implementation resist the attack while retaining interoperability:

The basic ssh message framing is:

  uint32    packet_length
  byte      padding_length
  byte[n1]  payload; n1 = packet_length - padding_length - 1
  byte[n2]  random padding; n2 = padding_length
  byte[m]   mac (message authentication code); m = mac_length

As documented, the "mac" is transmitted in the clear; everything
before that is encrypted.

    Padding
      Arbitrary-length padding, such that the total length of
      (packet_length || padding_length || payload || padding) is a
      multiple of the cipher block size or 8, whichever is larger.
      There MUST be at least four bytes of padding.  The padding SHOULD
      consist of random bytes.  The maximum amount of padding is 255
      bytes.

With the 4-byte minimum, the random padding puts a floor on the
difficulty of guessing the previous block (no better than one chance
in 2**32).  An implementation could render the attack entirely
meaningless by always sending a full cipherblock of padding...

					- Bill