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

["denis bider \(Bitvise\)" <ietf-ssh2%denisbider.com@localhost>]

I'm kinda surprised by the attitude "there's only one zlib".

We use the Crypto++ implementation, which is independent of zlib, and is 
freely available.


----- Original Message ----- 
From: "Niels "Möller"" <nisse%lysator.liu.se@localhost>
To: "Peter Gutmann" <pgut001%cs.auckland.ac.nz@localhost>
Cc: <djm%mindrot.org@localhost>; <mouse%Rodents-Montreal.ORG@localhost>; <ietf-ssh%NetBSD.org@localhost>
Sent: Saturday, April 18, 2009 15:31
Subject: Re: applying AES-GCM to secure shell: proposed "tweak"


> Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:
>
> > 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.
>
> Is it primarily the attack surface of inflate (uncompressing) untrusted
> data that worries you, or also deflate (compressing)?
>
> The reason I ask is that
>
> * Inflate should be inherently less complex to implement than deflate,
>
> * 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.
>
> Regards,
> /Niels