Re: Core draft last call update.

[Bill Sommerfeld <sommerfeld%orchard.arlington.ma.us@localhost>]

> What about the attack described in Appendix C of
> <URL:http://eprint.iacr.org/2001/045/>, which appears to be
> applicable to the SSH binary packet protocol as specified in
> draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or
> counter mode is used)?

This attack has greatly increased difficulty for SSH because the SSH
MAC also covers the random pad at the end of the message.  As a
result, you can only tell if m and m' are identical if the random
padding appended by the sender is identical.

Quoting from the transport draft:

   After key exchange, the selected MAC will be computed
   before encryption from the concatenation of packet data:

     mac = MAC(key, sequence_number || unencrypted_packet)

   where unencrypted_packet is the entire packet without MAC (the length
   fields, payload and padding), and sequence_number is an implicit
   packet sequence number represented as uint32.

The chance of this happening depends on the message length -- ssh
requires at least 4 bytes of padding, and requires that messages be
padded to a multiple of the block size and a multiple of 8.

If the implementation inserts the minimum padding, this will be
between 4 and 11 bytes (and it can always insert more).

The most "interesting" case is, of course, a single byte of channel
data, which will get a minimum of 9 bytes of padding.

You also only get one shot at this per connection -- the peer will
drop the connection and forget the session key if you get it wrong.

Compression will complicate this attack as well.

					- Bill