[Top] [All Lists]

Re: hand huffman encoding at PGP world HQ

1997-11-23 13:07:29
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).