Re: Albrecht/Paterson/Watson's attack

[nisse%lysator.liu.se@localhost (Niels Möller)]

Simon Tatham <anakin%pobox.com@localhost> writes:

> I suppose, on the other hand, that if people still disliked having
> message lengths in clear, then you could tweak this concept using the
> suggestion from the paper referenced upthread of having a MAC covering
> just the length field or just the first cipher block or some such, so
> you'd get a chunk consisting of (encrypted length, MAC of encrypted
> length, encrypted rest-of-data, MAC of encrypted rest-of-data).

I'm pretty sure I'm missing something subtle here. We first get a packet
length, and then we read an encrypted message of that length from the
network, check the mac and decrypt it (assuming we have configured some
-etm mode of operation). To communicate that packet length, we
have a couple of different options:

1. Cleartext packet length, no crypto, no mac.

2. Encrypted packet length, no mac.

3. Encrypted packet length, with a separate mac.

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.

Is there any easy explanation for that? I realize that the first
decrypted block includes both length and a prefix of the cleartext
message, which possibly is the source of the problem, but if everything
but the length part is ignored until after successful verification of
the mac, it's not clear why that's a problem.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.