Re: [RFC] CryptoAPI & Compression

["Artem B. Bityuckiy" <dedekind@yandex.ru>]

Herbert,

I also wonder, does it at all correct to use negative windowBits in 
crypto API? I mean, if windowBits is negative, zlib doesn't produce the 
proper zstream header, which is incorrect according to RFC-1950. It also 
doesn't calculate adler32.

For example, if we work over an IP network (RFC-2384), the receiving 
side may be confused by such a "stripped" zstream.

Isn't it conceptually right to produce *correct* zstream, with the 
header and the proper adler32 ?

Yes, for JFFS2 we would like to have no adler32, we anyway protect our 
data by CRC32. But I suppose this should be an additional feature.

Comments?

Herbert Xu wrote:
> > I made the changes to deflate_decompr() because the old version doesn't
> > work properly for me. There are 2 changes.
> >
> > 1. I've added the following code:
> >
> > ------------------------------------------------------------------------
> > if (slen > 2 && !(src[1] & PRESET_DICT) /* No preset dictionary */
> >    && ((src[0] & 0x0f) == Z_DEFLATED)  /* Comp. method byte is OK */
> >    && !(((src[0] << 8) + src[1]) % 31)) {      /* CMF*256 + FLG */
> >    stream->next_in += 2;
> >    stream->avail_in -= 2;
> > }
> > ------------------------------------------------------------------------
>
> The reason you need to add this is because the window bits that
> was used to produce the compressed data is positive while the window
> bits crypto/deflate is using to perform the decompression isn't.
>
> So what we should do here is turn window bits into a configurable
> parameter.
>
> Once you supply the correct window bits information, the above is
> then simply an optimisation.
>
> Rather than keeping the above optimisation, JFFS should simply do
> the compression with a negative window bits value.
>
> Of course to maintain backwards compatibility you'll need to do this
> as a new compression type.
>  


--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/