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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Sun, Apr 19, 2009 at 05:41:03PM +1200, Peter Gutmann wrote:
> nisse%lysator.liu.se@localhost (Niels =?iso-8859-1?Q?M=F6ller?=) writes:
> >Is it primarily the attack surface of inflate (uncompressing) untrusted data
> >that worries you, or also deflate (compressing)?
> 
> Purely inflate.  I'd be kinda surprised if you could cause problems with input
> data, at best you can cause O( n^2 ) behaviour until the hash chain truncation
> takes effect.
> 
> >* Inflate should be inherently less complex to implement than deflate,
> 
> Have a look at the source code :-).
> 
> >* I'm awere of an alternative (but unfortunately proprietary) implementations
> >of inflate that is claimed to be smaller and simpler than the original one in
> >zlib.
> 
> Also less audited/less exposed to attack and scrutiny.  Insert standard open-
> vs. closed-source argument here.  The real issue though isn't to try and
> figure out which one is less risky, but a basic "don't do that, then".

+1.

Don't compress/uncompress in privileged code.  By and large it's easy to
separate privilege post-authentication (since privilege will be needed
only for things like logout processing).  So postponing compression till
after authentication would be a good thing.  Besides, there's nothing
much worth compressing between version banner exchange, key exchange and
authentication (well, if we keep adding algs then KEXINIT may become
significantly compressible :)

Nico
--