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

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

Damien Miller <djm%mindrot.org@localhost> writes:

>Avoiding the attack surface presented by compression libraries before
>authentication of the user.

This is pretty much the main reason why I haven't implemented it so far.  zlib
has had quite a number of security holes, and (from looking at the code in the
past) there are no doubt lots still in there - it's a huge body of incredibly
complex and not entirely comprehensible code (do you want to analyse
inflate.c/inffast.c and check that there's no potential for
overflow/underflow/overwrite/whatever in there?).  Having all that exposed to
arbitrary remote attackers is too big a risk to take.

(I've never really understood why the compression starts where it does anyway,
what's being exchanged at that point is mostly random incompressible binary
gunk so it has little to no effect on data size anyway).

>http://tools.ietf.org/html/draft-miller-secsh-compression-delayed-00

Hmm, why not just apply it only to the data packets?  The random non-data-
related messages exchanged (again, mostly high-entropy binary blobs) aren't
going to compress much (if at all), and will only have the effect of messing
up the compression by polluting the source statistics.  With data-payload-only
compression it'd be much cleaner and easier to handle, just run the compressor
over the data-packet payload and leave everything else as is.

Peter.