Subject: Re: an attack against SSH2 protocol

From: nico <[email-masked]>
Date: Sun, 24 Mar 2002 04:20:28 -0500

On Fri, Feb 08, 2002 at 02:50:29PM -0500, Bill Sommerfeld wrote:
> 
>     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...

This would pretty much be the equivalent of starting encrypted messages
with confounders. The "modern" Kerberos crypto spec relies on
confounders instead of explicit IVs (which are worse than implicit IVs).

So why not?

Alternatively a new global request could be spec'ed to negotiate the use
of confounders instead of implicit IVs.

> 					- Bill

Nico

---

From: Markus Friedl <[email-masked]>
Date: Sun, 24 Mar 2002 17:02:30 +0100

> of confounders instead of implicit IVs.

you cannot use SSH_MSG_GLOBAL_REQUEST, it's part of
the connection protocol, a different layer.

---

From: nico <[email-masked]>
Date: Mon, 25 Mar 2002 23:24:59 -0500

> the connection protocol, a different layer.

Yes, you're right, that would be a violation of the layer abstraction.

Fine, so come up with new enctypes matching the existing CBC enctypes
but whose semantics will be "same as previous version, but with this
enctype all messages must start with a confounder".

Also, I find it weird that the draft uses "SHOULD" wrt treating the last
cipher block of a message as the IV for the next message. I can't see
how two implementations can operate if one does and the other does not
treat the last block of each encrypted message as the IV for the next.

Of course, that must be a SHOULD because this implicit IV rule might not
apply to some enctypes, but then, that should be specified per-enctype,
and, for the ones that use implicit IVs it should be a MUST. I.e., this
part of the connection protocol draft probably needs revision.

Cheers,

Nico