The last time I vented about this issue (I think on this list) someone
relayed that at PGP they had gone stomping around the office singing
"every bit you save, we'll be watching you,..." to the tune of the
"every move you make, ..." melody.
It was "Every bit is sacred, every bit is great, if a bit gets wasted, Phil
gets quite irate", but your suggestion is equally appropriate.
I hereby call for length fields to be universally encoded as a 32 bit
integer. And all the above bit twiddling to be trashed. Relegate LOL
(length of length) and all the other length bit twiddling to MAY for
backwards compatibility.
I would also argue for scrapping the non standard CFB hack (resyncing on
semantic boundaries) and putting in place standard cipher-block-sized CFB.
I agree with both of these in principle, but how much hassle will it cause for
implementors (and existing users)? If you do this then you're completely
breaking compatibility with existing implementations, in which case you may as
well do it properly and use ASN.1 or something similar which allows you to
write a very precise definition of the message format which is simultaneously
usable as the input to a parser which interprets the format. At the moment
every PGP implementation has to be hand-coded and tuned, creating the
potential for any number of bugs and problems, as Adam has pointed out.
(The 32-bit fixed length may be a problem in the future when files grow over
4GB. Can the PGP encoding handle > 4GB data units at all?).
It depends on how essential backwards compatibility is - if you're going to
break it, it would be nice to move other things more into line with what the
rest of the world is doing (eg use real X.509v3 cert extensions rather than
trying to reinvent them yourself and ending up with something which is
functionally identical to, but completely incompatible with, the X.509 certs
which everyone else uses).
Peter.