Re: applying AES-GCM to secure shell: proposed "tweak"

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

>That makes sense to me (and seems well-defined, at least once you specify
>precisely what "data packets" are, presumably SSH_MSG_CHANNEL_DATA, maybe
>SSH_MSG_CHANNEL_EXTENDED_DATA, possibly a few others such as
>SSH_MSG_CHANNEL_WINDOW_ADJUST).  I may try implementing it.

Yup, I was thinking specifically of CHANNEL_DATA and EXTENDED_DATA, and just
the payload, not the header.

>There are a lot of non-data messages that are full of uint32 fields that
>typically have at least 3/4 of their bits zero. Some even use a 32-bit field
>to carry one bit of information. Compressing these is valuable from the point
>of view of providing higher-entropy data as the cleartext to the encryption
>algorithm and therefore making it harder to attack.

Uhh, so breaking AES is going to be possible if the content is uncompressed
but not if it's compressed? :-).  That's a pretty theoretical objection...

In terms of compression, I'm not so sure that compressing the headers is a
good idea.  If you look at the Calgary compression corpus the least-
compressible file in there is 'geo', which consists of lots of 32-bit ints
with high bits zero.  The reason for this is that most context-based
compressors are really bad at modelling counting events (every n-th byte zero,
that sort of thing), there are some special-case ones like DMC that handle
this a bit better but that has some other problems that make it impractical,
and I'm sure everyone else on the list has gone to sleep by now.  Without
running some tests it's hard to say what the effect will be, but I suspect
it's not going to be quite as good as expected.  It could also be rather
situation-specific, for example if you're using SSH for secure logging then
having the nice compressible stream of text records periodically broken up by
binary blobs probably isn't a good idea.

Peter.