[Top] [All Lists]

Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)

2001-11-08 01:43:58

Hash: RIPEMD160

Werner Koch wrote:

On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said:

answer.  The issue was that GnuPG used an old-style indeterminate-length
packet for the plaintext before the MDC (see my message of August 23

But only if the plaintext is a compressed packet - right?


rfc2440b03> 4.2.1. Old-Format Packet Lengths
rfc2440b03> [snip]
rfc2440b03>    The meaning of the length-type in old-format packets is:
rfc2440b03>    3 - The packet is of indeterminate length.  The header is 1 octet
rfc2440b03>        long, and the implementation must determine how long the 
rfc2440b03>        is. If the packet is in a file, this means that the packet
rfc2440b03>        extends until the end of the file. In general, an 
rfc2440b03>        SHOULD NOT use indeterminate length packets except where the 
rfc2440b03>        of the data will be clear from the context,

it does not talks about compression,
so I think it should be the same for any packet type

rfc2440b03> 4.2.3. Packet Length Examples
rfc2440b03> [snip]
rfc2440b03>    An implementation MAY use Partial Body Lengths for data packets, 
rfc2440b03>    they literal, compressed, or encrypted. The first partial length
rfc2440b03>    MUST be at least 512 octets long. Partial Body Lengths MUST NOT 
rfc2440b03>    used for any other packet types.

so it is ok for all data packets..

rfc1991> 4.1  Packet structure fields
rfc1991> [snip]
rfc1991>       11 - no packet length supplied, unknown packet length
rfc1991> [snip]
rfc1991>    A value of 11 is currently used in one place: on compressed data.
rfc1991>    That is, a compressed data block currently looks like <A3 01 . .  
rfc1991>    where <A3>, binary 10 1000 11, is an indefinite-length packet. The
rfc1991>    proper interpretation is "until the end of the enclosing structure",
rfc1991>    although it should never appear outermost (where the enclosing
rfc1991>    structure is a file).

'currently used in one place' is not the same as 'MUST/SHOULD be used in one 
so I think it's ok to use 'unknown packet length' for other than compressed 

but gpg implements this different way than in RFC1991 and RFC2440:

doc\DETAILS> Packet Headers
doc\DETAILS> [snip]
doc\DETAILS> +  It works like this: After the CTB (with a length field of 11) a
doc\DETAILS> +  marker field is used, which gives the length of the following 
doc\DETAILS> +  This is a simple 2 byte field (MSB first) containing the amount 
of data
doc\DETAILS> +  following this field, not including this length field. After 
this datablock
doc\DETAILS> +  another length field follows, which gives the size of the next 
doc\DETAILS> +  A value of 0 indicates the end of the packet. The maximum size 
of a
doc\DETAILS> +  data block is limited to 65534, thereby reserving a value of 
0xffff for
doc\DETAILS> +  future extensions.

other interoperability problem is that gpg puts
signature after the data packet, pgp expect it before..
I think it is because gpg wants to do all in
one pass without seeking or using temporary files.

Disastry <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1


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