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

[nisse%lysator.liu.se@localhost (Niels Möller)]

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