ietf-openpgp
[Top] [All Lists]

Re: partial packet lengths in PGP 8

2003-04-08 20:20:41

"Brian Smith" <sbs(_at_)hush(_dot_)ai> writes:
It seems to me that PGP 8 does not support partial packet lengths for
a a symmetrically encrypted data packet.  Is this a known bug, and if
so is there a work-around?

I worked on predecessors to PGP 8, and based on your test data I can
confirm that there is a bug in the packet parsing code relating to
partial body lengths.  It's not specific to symmetrically encrypted data
packets, but rather to the "initial" portion of the packets.  Many of
the PGP data packets have an initial part which is of more or less fixed
length, followed by the rest of the body which can be of arbitrary length.
The parser first assembles the initial portion and extracts the data from
that, then falls into some relatively generic code which handles the rest
of the data.  There is a bug in the parser which won't work properly if
the initial portion spans two or more partial-body-length packets.

In the case of symmetrically encrypted data packets, the initial portion
is the first 10 bytes (for 8-byte ciphers; 18 bytes for 16-byte block
ciphers).  In your case you had a PBL of 8 followed by two PBL's of 1
each to fill out the first 10 bytes, but the code messes up and doesn't
assemble the packets correctly.  It doesn't do what you might think and
include the e0's in the packet, but it fails to update the buffer pointer
and so replicates the contents of the previous PBL, the 96 and 97 bytes,
as the 9th and 10th.

So the work-around in this case is to make sure the first partial body
length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes,
for 16 byte block ciphers.  That will mean buffering up the first 16 or
32 bytes of your stream before emitting your first block.

Hal Finney