Re: Albrecht/Paterson/Watson's attack

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

In article <E1WhcBC-0001yc-N3%login01.fos.auckland.ac.nz@localhost> you write:
> One thing that SSH would then need to do is to stop encrypting the header
> (that is, the length information) so you can run the MAC over the packet
> without having to pick apart bits of it via decryption first, which is what
> helps the Paterson et al attack work.

I think this idea has historically been unpopular in SSH circles
because the cleartext packet length fields were critical to attacks
against SSH-1. Of course, those were _particularly bad_ cleartext
packet length fields, but even so, it's unsurprising that people have
a reflexive aversion as a result...

Personally, if I were redesigning the SSH-2 binary packet protocol,
I'd be inclined to split it into two entirely separate layers, by
removing the coupling between semantic SSH protocol messages and
chunks of data encrypted/MACed as a whole. There's no actual reason
that the two should coincide.

So you'd start with a BPP designed solely for security, which would
consist of a series of (length, encrypted data, MAC) chunks stuck
end-to-end. The MAC would apply to the ciphertext, and the length
would be the full length of the ciphertext (or perhaps ciphertext+MAC)
in clear.

Once those chunks were MACed and decrypted, the decrypted ciphertexts
would be concatenated, and the resulting byte stream would be divided
into semantic SSH-2 messages according to a (length, type, data)
format about as simple as the one in SFTP (though you might also want
to provide a convenient way of including small numbers of bytes of
padding between messages, without having to construct an entire
SSH_MSG_IGNORE).

And the two notions of 'chunk' and 'message' have no particular need
to match up. So if you wanted to send lots of SSH-2 messages in one
go, you could combine them into a single chunk, and then the atomic
MAC covering the whole chunk would make it impossible for an attacker
to determine the boundaries between those messages (so, e.g., hiding
password length by combining the password with an SSH_MSG_IGNORE is
now clearly not defeatable by proxying the TCP stream and dribbling
out bytes one by one until you see a response). Conversely, a very
large message could be split across multiple chunks if you felt like
it, or an SSH_MSG_IGNORE could start at the end of one chunk and
finish in the start of the next.

Hence, the cleartext length field on the _chunk_ doesn't necessarily
tell you anything about the length of any _message_ within that chunk.
Indeed, it doesn't even tell you anything you couldn't deduce from
the TCP segment boundaries, which is my rationale for it not being an
unreasonable exposure of information. (In particular, the cleartext
length field would always be a multiple of the cipher block size.)

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).
-- 
Simon Tatham         "A cynic is a person who smells flowers and
<anakin%pobox.com@localhost>    immediately looks around for a coffin."