From 3.2:
The length field of an MPI describes the length starting from its most
significant non-zero bit. Thus, the MPI [00 02 01] is not formed
correctly. It should be [00 01 01].
This is required by most earlier versions of PGP (through 2.7.1) for
signatures, but not apparently for encryption or decryption. It is not
required by 5.0. Note that many RSA implementations return the value the
same length as the modulus, which can include leading zeros.
Also note that the above bad example would work with the earlier versions
of PGP - it simply requried the leading byte not be zero.
So, how strict is the MPI format requirement? (another "should" v.s.
"must" debate).
---
It would help greatly if there was some minimum specification about when
data will *NOT* be split into chunks with the new CTB length scheme.
e.g.
0xca 0x03 'P' 'G' 'P'
is easy to handle, but it would seem that
0xca 0xe0 'P' 0xe0 'G' 0xe0 'P' 0x00
is equally valid (I made this up, so may have erred in the details).
I don't want to create another state machine and I/O abstraction layer
when I don't have to, and PGP 5.0 doesn't arbitrarily do things like the
above.
What I would like is that for things like any CTB valid within a keyring,
and short (<8381 or whatever) comment type packets, that there will only
be *ONE* length entry of one or two bytes as appropriate. If this sounds
like it makes sense, I can come up with a comprehensive list, but
generally I would only permit it for things that are inherently variable
in length (like file data contents).
---
Should the new length format be used for compressed blocks? If the
compression algorithm will know (or can determine) the length, it is much
simpler than having to have one state machine to feed the (de)compressor,
and another to dechunk the data stream. In fact, it is cleaner to create
a dechunk | decompress pipe, though less efficient, than the merged code -
some of the ugliest stuff I have written.
I haven't tried generating things with these tiny length-continue segments
to see if PGP can handle them. But for smaller machines (e.g. palmtops
and PDAs) it would be better not to have to worry about this.