Currently we have two mechanisms for expressing the lengths of packets,
described in section 4.2 of the spec.
The "old" method, from PGP 2.X, uses a length-of-length field in the
low order two bits of the CTB. This field tells whether the following
one, two, or four bytes contain the length of the packet (or whether
the packet is indefinite-length, meaning that it occupies all remaining
space in the input).
The "new" method, introduced in PGP 5.0 to free up bits in the CTB and
to support one-pass processing, uses a self-delimiting length value.
If the length is less than 192, it is expressed as one byte. If it is
from 192 to 8383, it is expressed as two bytes with a certain
encoding. Packets of length 8384 bytes and up, along with packets for
which the length is not known in advance, are divided into pieces
which are powers of two, and each piece is preceded by a partial-length
byte, which is 0xe0 plus the log base 2 of the size of the piece.
It is awkward that packets of size greater than 8383 must be broken up
into pieces and have partial-length bytes inserted into them. This
requires reassembly on the receiving end, with the partial-length bytes
being snipped out.
I propose that we modify the new encoding slightly so that we can easily
express packet lengths larger than 8383 bytes. We would add an optional
four-byte length encoding, which would be indicated by having the first
byte be 0xff. When this is the first byte of the length field, it would
mean that the following four bytes would be the length of the packet.
Presently, a length byte of 0xff is interpreted as a partial-length
byte with length 2^31 or 2 GB. We would eliminate this interpretation
in favor of the new one. This is only a small loss of functionality,
since if partial-length packets are being used, the pieces will
probably be much smaller than 2 GB.
Comments?
Hal Finney
PGP, Inc.
hal(_at_)rain(_dot_)org