Re: Albrecht/Paterson/Watson's attack

[Simon Tatham <anakin%pobox.com@localhost>]

nisse%lysator.liu.se@localhost (Niels =?iso-8859-1?Q?M=F6ller?=) wrote:

> You seem to be saying that (1) is secure (except that the exposed
> lengths are unfortunately meaningful also above the ssh transport layer)
> and that (3) is secure, but that (2) is a problem.

Sorry to have been unclear! I may well not have thought it through
adequately myself. But what I was getting at here is two separate
attacks:

 (a) the subject of the whole paper, i.e. an attack on the encryption
     which involves substituting an initial cipher block and inferring
     from the subsequent failure mode some information about the
     length field to which it decrypted. Putting the length field in
     cleartext rather than in the first cipher block defeats this
     attack.

 (b) the DoS attack which the paper mentions in passing as being
     potentially opened up by having the length field in cleartext: an
     active attacker replaces the length field with a very large one
     and sends a big pile of data, causing the receiver to buffer it
     all and use up a lot of memory. The paper admits that this may
     not be something you particularly care about.

The option you list as (1), i.e. a cleartext unMACed packet length,
defeats attack (a), but it struck me that people might still dislike
cleartext packet lengths for some other reason(s), possibly including
attack (b).

Option (2), putting the packet length back into the encrypted data
without a separate MAC, risks reintroducing forms of attack (a), i.e.
decryption oracles based on the fact that the decrypted packet length
affects the receiver's behaviour before the MAC on it is checked.

Option (3), encrypting the packet length and MACing it separately,
defeats both types of attack as far as I can see.

(And I don't think it matters whether the packet length lives on its
own in a separate cipher block or whether it's combined with the first
n-4 bytes of the payload. As long as a fixed number of cipher blocks
are covered by the first MAC, and that MAC is verified before taking
any action based on the length field, I think it should be OK either
way.)
-- 
Simon Tatham         "Happiness is having a large, warm, loving,
<anakin%pobox.com@localhost>    caring, close-knit family in another city."