Re: [security-services] Bug in the bindings doc; wrong RFC

[Greg Whitehead <grw@trustgenix.com>]

Ok, I think I've decoded (inflated? ;-)) the RFCs.


rfc1951 (Deflate) says:

          Each block of compressed data begins with 3 header bits
          containing the following data:

             first bit       BFINAL
             next 2 bits     BTYPE

          BFINAL is set if and only if this is the last block of the data
          set.

          BTYPE specifies how the data are compressed, as follows:

             00 - no compression
             01 - compressed with fixed Huffman codes
             10 - compressed with dynamic Huffman codes
             11 - reserved (error)

	...


rfc1950 (ZLIB) says:

       A zlib stream has the following structure:

            0   1
          +---+---+
          |CMF|FLG|   (more-->)
          +---+---+

       (if FLG.FDICT set)

            0   1   2   3
          +---+---+---+---+
          |     DICTID    |   (more-->)
          +---+---+---+---+

          +=====================+---+---+---+---+
          |...compressed data...|    ADLER32    |
          +=====================+---+---+---+---+

       CMF (Compression Method and flags)
          This byte is divided into a 4-bit compression method and a 4-
          bit information field depending on the compression method.

             bits 0 to 3  CM     Compression method
             bits 4 to 7  CINFO  Compression info

       CM (Compression method)
          This identifies the compression method used in the file. CM = 8
          denotes the "deflate" compression method with a window size up
          to 32K.  This is the method used by gzip and PNG (see
          references [1] and [2] in Chapter 3, below, for the reference
          documents).  CM = 15 is reserved.  It might be used in a future
          version of this specification to indicate the presence of an
          extra field before the compressed data.

       CINFO (Compression info)
          For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
          size, minus eight (CINFO=7 indicates a 32K window size). Values
          of CINFO above 7 are not allowed in this version of the
          specification.  CINFO is not defined in this specification for
          CM not equal to 8.

	...


So, the first observation is that it really wouldn't be that heinous to 
use rfc1951, if we wanted to do that -- as long as we restricted CM to 
8 (deflate). I still think we were correct in specifying rfc1950, 
however, so let's do some experiments...


Running a test with the Deflater/Inflater classes in JDK1.4 
(java.util.zip), I get the following results:

grw$ java DeflateTest

def_wrap.length=8
78 9c 3 0 0 0 0 1

def_nowrap.length=2
3 0

In the first case, the 'nowrap' argument to the Deflater is false (so 
the ZLIB header and footer are added). In the second case, the 'nowrap' 
argument is true, so we just get the deflated data. Note that I was 
deflating zero-length data in these tests, so all we are seeing are the 
headers etc.


So, it looks to me like the JDK classes do what we need, even if the 
documentation is a bit confusing (ie one could argue that the 'nowrap' 
behavior should be the default).

-Greg


On Feb 7, 2005, at 3:59 PM, Scott Cantor wrote:

>> In Java, It looks like one can use Deflater with the constructor that
>> takes the 'nowrap' parameter.
>
> Maybe, but there's some worrisome language in there about dummy bytes 
> and
> GZIP. The hardest part is finding something anybody can be confident 
> in.
>
> zlib might have been a better choice, but it's very much a tactical 
> decision
> and if Sun changed the class (a stretch I admit), then what?
>
> Got to be some kind of "official" benchmark for what's intended 
> somewhere,
> clearly. zlib itself might be a reasonable starting point, but again, I
> don't know what options/functions to use to avoid the header.
>
> -- Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> security-services-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: 
> security-services-help@lists.oasis-open.org