ietf-openpgp
[Top] [All Lists]

Re: CTB and Length Type 3

1998-05-09 16:13:38
On Sat, 9 May 1998, William H. Geiger III wrote:

Hi,

I am having a little problem in parsing signed messages following the
draft documentation.

Both PGP 2.6.x & 5.0 produce the following (output as binary file):

A3 01 01 AF 00 50 FF [remained is signature block]

I take it you compressed a zero-byte file?  The problem is a bug in PGP
signing zero byte files, where instead of doing something right, it does
what you show above, and something more (read on).

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
... 
Obviously this is not the case as the compressed data packet does not
cover the entire file as there is a signature packet that follows.

Buried in some old 2.6.2 docs it says something different.  Functionally a
type of 3 means that the function, i.e. algorithm can determine when the
EOF is (which zip does).

Now the next octet (01) represents zip compression algorithm.

Where I am having problems is with the remaining 5 octets. I have read
through RFC1591 and I am still lost at decodeing the remainder of this
compression packet.

At this point I am not intrested in Inflating the data but calculating the
length of the compressed packet so I can find the start of the sig block
for sepeate processing.

You must inflate (to /dev/null if needed or simply dump the stuff in the
output buffer) as the only way to know where the compressed data ends.

Also Section 10.2 does not seem accurate as:

This is a bug in PGP since if you have even one byte of data, what would
be compressed would be sig,literal(data).

Also you might notice a trailing literal with the file type, name, and
time, but with zero bytes.  So the actual format might be
(zero byte compressed packet)(signature packet)(literal packet).

--- reply to tzeruch - at - ceddec - dot - com ---


<Prev in Thread] Current Thread [Next in Thread>