The whole system is pretty hokey, though there's definitely some value
in tight-packed formats within key certification handling blocks
to keep them short. The question is how to phase out the old stuff
as fast as possible without abandoning users of older software.
(Incompatibility has, of course, really annoyed a lot of users.)
My recommendation is to adopt the proposed 0xFF + 4-byte-length
with some kind of flag mechanism for initial transition, and
deprecate the old stuff, using the new indication whenever possible --
but _only_ when possible. (Is it possible to shoehorn into PGP 6.0?)
Actually, if you're using a flag, you _could_ perhaps skip the 0xFF.
One of the most serious problems with the hokey number formats
is that it increases the parsing code size and work level
on every user of PGP - this is a pain for smartcards and
other limited-memory environments. Perhaps a flag approach
would let us replace _all_ the hokey packed number formats?
I suppose processing time isn't _that_ important, given that
parsing silly number formats is much faster than RSA or DH.
Is there a corresponding _advantage_ to using usually-short
numbers in 16-bit processing environments?
What kinds of lengths need to be dealt with? How common are they?
In particular, is 4 bytes enough, or if we're extending anyway
should we just do 8 bytes?
0) Zero - is this needed anywhere?
i) Indefinite - critical for one-pass transactions; series of
blocks of some reasonable size like 8KB or 1MB or whatever
followed by a smaller block at the end (or padding) are fine.
They don't add a high percentage of size, though they
make things non-even multiples of disk block size, which
is annoying for efficiency.
1) Small - lengths of packets in key records and certifications.
Has anybody at PGP done a study of the existing certs
in the existing key servers to determine what size packets
are used? For instance, how often is 192 enough?
What fraction of them overflow into 83xx?
2) Text messages - many ASCII email messages fit into 8KB,
so the 2-byte format does save 2 bytes over a 4-byte,
but that's guaranteed to be <~ 1% of message size,
and probably averages about 0.1% - 0.05%, given the
typical 1KB of headers and 1 page of text in ASCII email.
3) Word-processor documents, GIFs, and small programs
Microsoft email programs traditionally choke on
ASCII bigger than 30KB, and MS encourages you to attach
semi-bloated word-processor documents or really-bloated
PowerPoint pictures, or to use semi-bloated rich-text formats.
This is all bigger than 8KB, and often bigger than 64KB,
but probably isn't bigger than 16 MB very often.
4) < 2-4GB - Almost any document except some MPEGs,
CDROMs (until DVD replaces them),
ZIP and JAZ drives (until they get bigger than 2GB),
file system backups (starting to get bigger, and tape
drives have been over 2GB for a while).
5) >2-4GB - DVD, bigger disk drives - while you usually
would use a file system encryptor rather than PGP,
PGP is still an interesting format for encrypted backups,
and people _are_ going to do this sort of thing,
especially as DVD lets them make high-res encrypted movies.
On the other hand, operating systems often get cranky
about allocating memory bigger than 2GB or 4GB, and
code with 32-bit integers often gets cranky about it,
and using indefinite-length formats for files
bigger than this increases your size by 10**-9,
and is mainly annoying because things aren't
even powers of 2 or multiples of 1KB.
Thanks!
Bill
Bill Stewart, bill(_dot_)stewart(_at_)pobox(_dot_)com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639