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

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 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? :-)

Perhaps.  As a cryptographer I'm strictly a dilettante, but even I know
that the lower the entropy of the plaintext, the easier it is to attack
an encryption algorithm.  Knowing that most of the bits are zero could
be the edge that makes the difference between working and failing for
some attack - especially since you mostly know which ones they are (the
high-order bits of most uint32s).

> That's a pretty theoretical objection...

At the moment, yes.  But attacks only get better....

> In terms of compression, I'm not so sure that compressing the headers
> is a good idea.

I'm not sure either.  I suspect the right thing to do is to implement
various alternatives, instrument them all, and see what happens in real
use.  (Actually, I'd be tempted to implement _all_ the alternatives and
record the results: that is, on the sending end, run all these
different compression algorithms and record the statistics - what
actually gets sent on the wire can be whichever one is most convenient,
since it's the statistics of the cleartext that are of interest.)  I
have my guesses, of course, and you clearly have some of your own, but
nothing beats actual measurements.

> 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.

Perhaps - but, since consecutive log records are usually mostly
independent, it probably won't do too much damage, either.

Yes, it could well be situation-specific.  If I do the "do them all and
instrument" thing, I may leave the instrumentation infrastructure in
place in the shipped version and provide a way for people to turn it on
and collect the data to figure otu which form of compression works best
for their particular application.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B