-----BEGIN PGP SIGNED MESSAGE-----
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?
Werner
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
packet
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
implementation
rfc2440b03> SHOULD NOT use indeterminate length packets except where the
end
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,
be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03> they literal, compressed, or encrypted. The first partial length
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03> MUST be at least 512 octets long. Partial Body Lengths MUST NOT
be
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
place'.
so I think it's ok to use 'unknown packet length' for other than compressed
packets
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
datablock.
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
datablock.
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 http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----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)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1
iQA/AwUBO+lTFjBaTVEuJQxkEQO4ygCfYLMPK9yLSplSO1Gm8iGWTHZJibMAoNcs
HXqktgfnXYl4hg2158xR7UEd
=QaId
-----END PGP SIGNATURE-----